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\ (54) Title: SYSTEM AND METHOD FOR ENABLING APHJCAnON SERVER REQUEST FAfUWER 





(57) Abstract: System and method for enabKng applicaticm server request failcnier. For cadi andacationK 
r>< fonned by a cUent computer, a requesting thread may be opoable to utilize a custom wife-levd a- ■ 
<^ fwluie detection mechanisms may be built into the custom wire-level communication protocol so i 
2 faiJed request much sooner than if ihe thread uulized a standard conununicaiion protocol and relied on tfi 
^ system for notlHcation of fated requests. After sending a request to an application » 
'slccn" and then DoiocUc 





Reed ving no response to the poll message indicate that the ( 
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TITLE: SYSTEM AND METHOD FOR ENABLING APPUCATION SERVERREQUEST FAILOVER 

BACKGROUND OF THE INVENTION 



The present inventioii relates to the Held of aj^lication 



2. Description of the Related Art 

The field of application servers has recently become one of the fastest-growing and most iiD|xntaiit fi 
in the confuting industry. As web applications a 





kept separate. The qjplicatiaa sow space i 
often responsible for deploying and ma 




: significant advantages over previous i 
D gateway interface <CXjI) scrqits or p 
e tea web appHeatipn utilizing OGI scripts ox piogiaiin. The cBenl ci 
inay refcience a OGI pfogram on Ae web server, e.g, by refiEfencing « 
tiiteyprogram.pr. Generally, the CGI program runs on the web server itself, possibly ai 
in Older to dynamicaHy generate HTML content, and the web server retams the ontput of the program to the web 
browser. One drawback to this approach is that the web server may start a new process each time a CGI program or 
script is invoked, which can lesuU in a high processing overhead, impost^ a limit ab die nmOi^ of OCT prognms 
that can run at a given time, and slow down Ae perfoimance of the w* server. In ooiiinit ap pf ira l inm aeneu 
typically provide . means for enabling progimn. or nro™ eonaionents <hat are 



drawback of previous web appEcadon design models, suck as die use of<X3I progrmas. 
For exMi^ if • CXSI pitjpra needs to access a database, die program typical^ opens • 
1 dien closes die connecdon once it is done. Since opening and closing t 
connections aie expensive operations, diese operations may fiirther decrease die performance of die web • 
each time a CGI program runs. In contrast, application servers typically provide a means to pool dM 
connections, thus eliminating or reducing the need to constandy open/dose database canaeetion. Also, data m 
in CGI programs is generally coded at a relatively low level, e.g., using a specific dialect of SQL to a 



specific Qrpe of database. Thus, portions of the anilication may 



need to be receded if die database is replaced widk 



anew type 



of database. Application servers, on die odier band, may provide a database service for applications ic 



other of application services or may provide 
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utilize as as interftce between the application and tbe 
particular type of database. 

Applicatian Servers may also provide many 
reusable conqjoncnts for tasks that web ai 
incoiporate these services and compon 

. , « lu n:m\ .^te or the intesrated development envwomnent mqf 

Model (COM/DCOM). Bniapn» JavaBeans«« (EJBX etc, or the mtegra 

^ d or may extend standard component models m various wayfc 

i lis, is a partial list of *e type, of appUcation services or appHcation con,>onents ttat 
,„„yprovide. By leveraging these types of integrated, pre.buil. service. ««l cor^^ 
r Hc^devdopersmayrealizeasignificantreductioninapplicatioodevdopmerttte 



a for accessing vaiiooa 
I, such as SAP, Lotus Na«es. aCS, etc, or 6aoa^ 
b as ODBC. JDBC, eie. Also, ai noted abo 




Application servers may also provide 
s«««,t the standanllightweightDirectory Access PK^ 



AppUcation servers may 
may be considered 



indnde siqipart for perfoiming v 

]s such as Secure Sockets Layer (SSL). 




i» «™ide services enabling a wefc application 10 eaiilsr maiiilrin i 
• AppUcation servers may also provide services enammg -rr : 

..„.. Pafuiimng state ana sesswm mwi 

information during a user «si«i « "^^^^^J^^^J^j^]^^^ 

• ^^™.vrfso support caching the results ofapplication logic execution or caching the 
. Apphcationservcrsmayrisosupport ^ ^^ten.av be reused. 
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Application servm may also support result streaming, such as dynamically straining Wm output, wlud> 
rtmy be especially useful for large result sets involving lengtliy queries. A related service may enable an 
applicatian to easily display a large resuh set by breaking the resuh set down into smaller groups and 
di^ying these groi^ to the user one at a time. 

M«vwebapplicatiop»needtoperformvarioustypesof searching «rind«^ AppHcanon server, 

may also provide afplication services for indexing or searching vi 



AS noted above, many web applicadcms may perform various tyP« of complex. TwOA^ HMsactiias. 
Application servers may also provide support for managing these m^^^ trans««ian.. For ex»nplc dn. 
support may be provided via . «,fh«« con^onem modd suppcned by the appto^ 
Enterprise JavaBeans« component model, or via integration wid. third-party transaction process momtois. etc. 

It is often desirable to enable web applications to perform certain operations independently, as opposed to in 
„^m.userrequ«t For example, it may be desirable for «i applic«ian to automatically send . 



via email at regularly scheduled intervals. Application servers nay support the 




IS types of standard network application si 

y provide fliese types of services and may enable applications 



• WA applications often need to log various 
integrated logging service for wd> appKcalioii* 

taiging by the ««npl.«y list of computing services tta 
applications, it is apparent flat application servers may integrate a diverse range of services, 
aay interact wid. many different types of servers, systems, or other services. For exan^te. 
„„.y act as a ptotfonn hub com.ecting web servers, database servers/services, e-commerce servers/services^ le^ 
systems, or any of various other types of systems or services. Akey benefit of m«.yappl^ 
not only provide this service/system integration, but typically also ptovide 
management tools for perfomnng 

For exan^le. application servers may provide 
deployment, such as tools for source code control and versioning. bug tracking, woricgmup developmei-. . 
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Applkatioii senrert may also provide tools related to appUcation testing aid deployment, such as toob liar 
application prototyping, load simulation, dynamic code base updates, etc. Application servers may also provide 
tools for easily configuring the appBcation to utilize various of the appUcation server services described above. For 
example, administrators may use a tool to set the result caching criteria for particular appUcation components or 
5 pages, or may use a tool to specify which documents to index or to specify indexing mefliods, elB. 
One important class of appUcation server administrative tools pertains 
management and monitoring. Application servers may provide tooto for dynamically 
affecting application performance, e.g. by adjusting the application services and support 
For exainjle, application server tools may allaw adnmustiaton lo: 

10 

• dynamically adjust the number of database cqmiectionsinainlained in a database 



schedule or trigger events, such as events to sending e-mail reports to appUcati 




y mean ^t a 

_ ^i5ieplicaled «iiinlt9»te appUcation servers in a cluster, so d^ 
Tfaihne on one application server, user requests may be routed to and processed IV other a^ 

servers in the cluster. 

AppUcation server clustering may ah» i&ciUtate appUcation performance and scalability. AppBcatwn 
servers may be added to a ch«er in orfer to scak up the avarTaWe processing power 
35 Adv«.ugcously. appUcation servers often enable this type of scaling up to be down without re^puring change, to 



Work may be distributed across an appBcation server chister in different ways. For example, 
above. appBcation code may be repUcated across multiple appUcation servers in 
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request to be processed by any of these multiple appUcation seiveis. Also, application code may be logically 
partitioned over multiple servers, e.g, so that a particular application server is responsible fox perfomong panicolar 
types of op«aiion$. This type of application partitioning may help application performance in various ways. For 
exaniple, application partitioniiig may reduce the need for an application server to perform context switching 
5 between diflerent types of operations, such as CPU-intensive operations versus inpw|/pu^ut-intensive operations. 
Also, application partitioning may be used to match application processing to various physical characteristiGS of ■ 
system, such as network characteristics. For exanqile, data-intensrve application logk may be configured to run on 
an application server that is closest to a data source, in order to reduce the latencies assodatBd widi accessing 



In the case of qiplication code repKcation. where multiple application servers are capable of processing a 
given request, it is often desirable to route the request to the "beaf application server currently available to process 
the request, i.e., to the application server that wiH enable the request to be processed and die request resnhs to be 
returned to the client as quickly as possible. TTiis mapping of client requests to application servers is known as 



Given the types of critical ^Ueaiiaas diat may ran on applioition servers, application faihire lecovcfy 



is between a client convater, such as a web server, and the application servw. Hw tenn '^nqoest ftilovcr. 
as used herein, refers to mediods andied to prevent, detect, and/or recover from faihncs dnt occur once a cUeat 
coiiqmter performs a request and begins to wait on die request lesohs. Existiiig ai^^ 
20 approaches often suffer from various disadvantages. For cxan^le, die client compfnter m^ s^ on die iterating 
system to inform the client conqmter of broken connections, wluch may result in a nmdi hnger diaa necessary time 



SUMMARY OF THE INVitPi j jQN 
25 iteproUenaioudined above inay in large part be solved by a system and medmd for enabling 

. server xequttt failovcr. as described herein. TTie tppUtx&m term may sqipoit networked applications, sucfe as 
web applications or odier Intemet-based applications. The applications may run on a system including one or moie 
client conqmters, «*, web servers, diat perform requests referencing application conqxments running on m 
application server. The system may also be configured to utilize a chister of application servers in «*ich requests 
30 from the client conq)utet(s) are distributed across differem application servers. 

Few each application server request to be performed by a client conqjuier. a particular diread naming on 
the client computer may perform dwreqnesL Ibe requesting direads may be operable tow 
communication protocol, a 

failure detection rnechanisms may be buih into the custom wire-level c 
35 diread detects a failed request, e.g., due m a lost connection between die client convnter and die application server 
I appUcation server conqwter faihuc. etc, much sooner dian if die diread utilized a standard 
n protocol and relied on die client conqnter (qperating system for notification of failed requests. 
After sending a raiuest to an application server, a requesting throd may be operable to "sleq>", using 
standard operating system techniques. Tlie requesting diread may dien periodicaUy wake up to poU die application 
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server coinputcr to deteimine whether the request has fafled. In one enAodinient. this poUing is perfonned by tte 
requesting thread sending a User Datagram Protocol CUDP) message comprising infoimation idemifying the request 
,o the application server. Upon receiying the UDP message, the application server is operable to use the ieq.»t 
infoimation to determine &e stams of the identified request and mfomi the requesting thread of the request status. 

If the requesting thread receives a response fiom the appUcation server computer indicating that the 
,equestisnBtc«n«ntlybeingprocessed.thenfhei«questingthreadmayre-se»dthereq^^ Receiving no response 
to the poO message may indicate that the application server computer is offline. e.g. due to a faflure. In coe 
exnbodimem. the application server computer may be one node in an appKcation server chaler. as described dwve. 
In this case, the requesting thread may redirect the request to another applicndon server conpider. Tte requesdog 
d«ad may update information maintained on the cBent computer regarding the stidns of ««* in>liG«tiaii server 
computer, to indicate fliat the appUcation server computer to which the request was sent is a 
requests win then be sent to other computers in the epplieation server cius) 
poB the offline application server con^ periodically, in order to determine 



BPTBF DESCRIPTION OF THE DRAWINGS 
Otiber otgects and advantages of die invention wiU become qjparent upon 



FSgnre I iflustiates a typical arcWteetiBe for a web application util^ 
Rguxet 2A - 2C ilhistnte exenq^boy aichiiecures for nei 

Figuie 3 is a block diagram iDostiating one embodiment of an application at 

several systen^levdl services dnt mqr be a 



embodiments of a w«* server client wifli a web server pi 




Figure 8 illustiates a table of exemplary server load criteria that may be used in deciding w 
saver is best able to process a cmrent request; 
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Figure 9 illustrates a table of cxemplaiy application component perfonnance criteria that may be used in 
deciding which application server is best able to process a current request;. 

Figtue 10 illustrates an exemplaiy user intezface screen for setting server load criteria vahiei; 

5 

Figure 1 1 ilhistntei a user interface partial tree view of appUcalifa servers in an applicadon aenrer chistei; 

Figure 12 iDustmtes an exeinplaiy user interface screen for sct^ applicatioo con^onoit perfonnance 
criteiia vahies; 

10 

Figure 13 illustrates an exenpbiy user inter&ee screen for setting broadcast and update intervals for 
during load balancing infonnatian aniong appUcation servers in an applicatian ser^ 

Figure 14 ilhistratts an exenoplaiy user interface of a tool for enabUng admiuisuatora to spedfy "sikk/* 
15 load balancing for certain appKcationcon^xmenii; 

Figure IS is a flowchart 



Figure 16 is a flowchart diagram illustrating one enbodimBiit of a mefliad for dynamically diacovering 



Figure 18 is a flowchart diagram illusnating one embodiment of a mediod fiar peifinming atomic daas- 

Figuze 19 is a flowdiart £agram fllustratin« oie einbodiment of a method for enaUing JSP re^onse 

Figure 20 illasnates an exenqihay user interface of a tool for man a gin g message logging; 
Figure 21 illustrates an exen^laiy type of database table for logging messages; 

35 

Figure 22 illustiates an exenqjlaiy type of database tabk for logging HTIP requests; and 

Figure 23 is a flowdiait diagram illustrating one enbodimait of a method for han d lin g out-crf'-storage- 
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Whfle the invention is susceptible to various inodifications and alteraative foims, spedSc e 
Y of exai^le in the drawings and aie berein described id deufl. It should be u 



that drawiagf and detailed description thereto axe not intended to limit the invention to the particular foim 
disclosed, but on the contraiy flie invention is to cover all modifications, equivalents and alternatives falling within 
the spirit and scope of the present invention as ddined by flie appended daioB. 

DETAILED DESCRimON OF THE PREFEICRED EMBODIMENTS 

FiEUie 2 - Exemplary Applicati on Architectugei 

Figures 2A - 2C iOnstiate exemphuy architectures for networked an>lications ruaning en applicatim 
senrets. Ttee are. of course, many posai^karchitectnial variations, and Figures 2A-2C are exeniqi^ 

Figure 2A ilhistrates an exen^lary ardiitecture for a web application. In general, a 
be defmed as an Internet or Intranet-based application conqjrising a collection of resources diat are a 
through uniform resource locators (URLs). The resources may include web pages comprising HTML. XMI, 
scripting code such as Javascript or VBScript, or other types of dements. Tbe resources may also include aiiy of 
various types of executable programs or con^nems, such as CGI pi 
COKBA con^ionents, downloadable code sudi as Java classes a ActiveX c 
b1«> include any odier type of xeaource addressable Arough a URL. 

The endbodiment <a Rgue 2A ilhattates a client compuier 100 t 
Netscape Navigator or Microsoft Internet Explorer web browsers. It is noted that die web-browser need not be s 
web browser per se, bat may be any of various types of client-side applications that inchide web-browsing 
functionali^. For exan5>le. Microsoft Corp. provides programming ii 
various web-biowsing capabilities provided by the Microsoft Ii 

The wd> browser may run in aiv type of cliem computer 1 00. For exnrnple. the wA browser may TO 

desktop convuter or workstation running arv of v«ions operatii^ 

or the web browser inay nm in a pomblp compntmg device, sudi as a personal data aasistaii^ 
etc The clicBt compiiter 100 na^ use a network connection for communicating with a wd» server 104 via a 
network 102. sudi as flie Intemet or an IntraneL The chert network connection may be a connection of any type, 
such as a PPP or SUP dialt^ Knk. an Ethernet or token ring connection, as ISDN 



any of various types o 



I, etc Aldiough web applications are often 




particular communication protocols, sudi as HTIP or SSL. it is noted that any CI 
TCP-based p 

As the web server 104 receives a request fiom a dient computer 100, d 
^aatOy.d^ea^mibKtypcafiaaiaetiibcieqfisA Fore 
document 106. sudi as an HTML document, then the web server may process the request itseU; e.g., by renieving 
the docuuKrt ftom the wd> server's locd file system or from a locd cadK and returning the docuni« 
computer. For other types of requests, eg. requests referencing executable components, sudi as Java servlets, 
s, C program modules. CORBA components, etc, the web server may broker the request to 
Tl08. As described in more detaflbdow.flie web server 104 n 
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server ihrougb an in-piocess extension, such as an ISAPI or NSAPI extension. It is noted that it is possible to 
incoiporate the functionality provided by the web server into an intejgrated application server* 

The application server 108 may be configured as a part of an application server cluster, as described above 
and shown in Figure 2A.. Although Figure 2A illustrates an application server cluster with only two applicatitm 
S servers, it is noted that the cluster may comprise aiiy number of application servers. Each application server may 
interface with various types of odier servers or systems. For exanq>le, as illustrated in Figure 2A, the application 
serveis may communicate with » datatnae 1 10. Eadt apjdicatieD server in Ae cluster nmy interface widi the same 
systena, or die appUcatioB servers n»y differ m wfaidi systems (hey interface wMl For example. Figure 2B is 
similar to Figure 2A, but in (he embodimeiil of Figure 2B. application server -108B is shown to interface widi ■ 

10 legacy system 1 12. AppUcatton serven in a diister may not need to be in close physical proximi^ to each other. 

It is noted that, in altenutive enibodimaits, a client computer may communicate directly with an 
application server or application server cluster, without interfacing through a web server. Figure 2C illustrates a 
client con^uter 1 14 communicating directly wid> application servers 108. For exan^Ie, the applicatian servers 
may run an e nt e rpri se resource plaiming application, and die client compnter 114 may be a compater widim die 

15 enterprise diat is connected to dw qiplxcadon serven via a WAN. In diis example, die dient cmnpnter may ran 
"diick dienf" software, client software diat m tn p ri sft a portion of die entexpiise resource planning appUcadaB 
logic. The client conqintCT software may inteiiliwe direcdy widi executable progrwM 
application servers. e.g. through a protocol such as the Internet Intcr-Oit* Protocol (IIOV). 

As noted above. Figures 2A - 2C are exen^lary architectures only, and many variations are possible. As • 

20 small handful of examples of ahemative embodiments, multiple web servers may be present to receive requests 



widi a database. ^ppficatioB serven may intei&ce widi varioiu odier ^pes of system, nidi as specialised 



25 Kgute 3 - Service and Oanponent Management 

Applications that run on appUcation serven are often constructed irom various types of software . 
c o np o neaB or modules. These conqmnents may inchide conqjonents constructed according to a standard 
coiqioiient modeL Fen- exanqile, aii application may cam}»ise various types of standard Java^con^onents such as 
Enteiprise JavaBeans'™ compo n ents, JavaScrver Pages™, Java Servtets^. etc. An application may also comprise 
30 any of various other types of components, such as Common Object Request Broker ArchiteCtiae (CORBA) 
I Object Model (COM) components, or components constracted accordins to varrans 

Eadi request that an ap|dication server receives fiom a client may reference a particular applicatian 
coinponent Upon receiving a request, the appUcation server may determine the appropriate conqxment, invoke die 
35. conTonent, and return the execution results to the client. In various embodiments, it may be necessary (» desirable 
for difTerent types of applicatian server conq>onents to run within different envir onm e nt s. For example, an 
application server may suppon both con^nents written using die Java^p 
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Foi example. Figure 3 illustrates an application server 200 in which a process referred to as the ««ecntive 
server^ 202 mm. As shown, the executive server 202 interfaces with a process 204. referred to as a "Java server" 
and a process 206 referred to as a "OC-H- server". In this enibodiment. the executive server 202 niay receive client 
requests, assign the client requests to a particular thread, and forward the requests to either the Java server 204 or 
the ac++ server 206. depending im whether the requests reference a component that executes within a Java 
nmtime enviromnent or a aC++ runtime envimmnent The Java server or aC++ server may then lo«I and 
execute the appropriate component or roadnle. 

In addition to interfacing with the Java and OC++ servers, the executive server 202 may alsa manage 
various system-level services. For example, as discussed below, the executive server may manage a load balaneiiig 
service for i&iribuiios requests to odier application server con^mters in a chister, a request manager service te 
handMng incoming requests, a protocol manager service for communicating with clients using various protocols, an 



In addition to managing application components, the Java server 204 and the OC++ server 206 may also 
host and manage various application-level services used by the appUcation components. ' 
<f include services for managing access to dat 
nate and session management, services for caching o 



FignR 3 also iUusntes a process 208 referred to as the "adminisiiative server*. As described above, aa 
nvironment msy prov»e an administrative tool for adjusting various facwis affecting 
.plication execution and performance. In the embodiment of Figure 3. such an administrative tool may inteite 
with the administrative server 208 to adjust these factoB. For exan^le, the administrative tool 208 may be ei 
to adjust the event logging criteria used by the executive server's event-logging service. a#ist die n 
database connections pookdlwtteJ«w or OOW^ server's datt access service, etc. Hie admiaisirative s 
may also provide faitare recovery by monitoring the executive server. Java server. «idOe++seiver processes «id 



Figure 3 of course represeais an exenf»lary architecnire for managing application components, system- 
level services, and application-level services, and various other embodiments are contemplated. For example, 
although Figure 3 is discussed in temis of Java~ and OC++ eomponenis. various o 
be present for executing other types of software components or modules. Also, variou. eni. 

_ e Java server processes or CC++ 

nuniber of processes may be 



Keure 4 - Application Server System-Level Services 

ngme 4 iDustrates several system-level services whidi be 
requests. In one enibodiment. these system-level services may be managed by m execnrive server process sudi as 
described above with reference to the Figure 3 application server. 

Figure 4 illustrates a protocol manager service 220. H« protocol m»>ager service 220 is responrible for 
managing network communicationbetween the application server 230 andclientsoftheap^ For 
example. Figure 4 iBustrates a web server client 240 which comprises s sumdard « 
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242. The web server plug-in 242 may be any of various well-known types of plug-iis! enabling web servers to 
conanunicaie wiib other systems, including NSAPl, ISAPl, optimized CGI, etc. As shown, the protocol manager 
service 220 includes "listener" modules or components, e.g. an KSAPI listener, ISAPI listener, etc., for 
communicating with the web server plug-in. The listener modules may communicate with the web server phig-in 
5 via the standard HTTP or HTTPS protocols. 

Figure 4 also illustrates that other types of clients baides web servers inay connnunicate widi die 
application servez 230. For exan^jle. a cliexil computer 250 is shown. The cfiest compiiler 250 may run aa 
application program, such as a program written in Java™ or C++, that comnnmicatet with die spplicatian sewer 
230 using any of varioiu conuninication protocols. For example^ as shown in Figmc 4, the protocol manager 

10 service 220 may support sndprotocoU as nop, RNfI,IXX3M,OCL Service, or any frf" varioiu As 
an exanqde, an administration program for conifiguring an application server may communicate directly widi the 
application server 230 through such a protocol, rather than routing requests through a web server. 

As shown in Figure 4, aa application server may also include a load balancing service 222. In the case of 
application server clustering, requests may first be processed by the load balancing service in order to determine 

15 wither the request should be processed by the current application server or would be better served by forwarding 
the request to another applicatioo server in die cbster. Load balancing is discussed in detafl below. 

As shown in Figure 4, an applicadon server may also inchide a request mamigcir service 224. Onee die 
load balancing service determines dwt the current an>lication server should process die dieat request <if load 
bsfa nVi ^ .•« iippiie»Mg), the irquest manager service is resproisible for managing, the processing of the request As 

20 shown in Figure 4, die request manager service 224 may mclude several ccm^wnents or modules, siich as a request 
manager, a thread manager, and a queue manager. In one embodimqi^ client requests may be processed in a mnlti- 
dneaded&shioa. The diread manager module may manage a pool o 
one embodiment, the number of threads in die pool rnay be adjusted nssog SI 



25 thread manager module to anenqw to assign die client request to a diread. Ifnodireadsarecuiiendyavaihible.dwa 
the request manager module may call the queue manager module to queue the request until a thread becomes 
available. The queue manager module may maintain infoimatian regarding each dient request, sudi as the request 



30 Application Server Load Balandng 

As discussed above, it is often desirable to configure a chister of plication servers so dist dient leqoesli 
may be distributed across die duster, ix^ to perform application server load bslanciqg. Given die diverse nature of 
applications that may be deployed on application servers, it may be desirable to provide a system whose losd 
balancing criteria are highly configurable using many different fiictors in order to achieve optimal ^licatiaa 
35 perfonnance. This section discusses several load balancing methods. In various embodiments, application servers 
of diese load bahmcing methods or any combii»tion of the load balancing methods described. 
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Load Balancing Deteimined by Web Server Plug-lB 

One general approach which may be used in selecting an application server to send a request to is to leave 
the decision to the cKoit The client may keep track of the response times seen over time from various application 
servers and may choose to send requests to the aHjUcaticm server wifli the historically fastest response times. In 
many cases, the "client" of an appUcation server is a web server. As shown in Figure 4. a web server may have a 
web server plug-in which includes a load balancer component or module. This load balancer con^onent may be 
responsible for monitoring which application servers are available in a duster to service requests, may record *e 
response times seen for requests serviced by each application server, and may use thk infonnatimi lo determine 
most apprqpiale application server to send ■ given ieq»e« to. 

The load balancer convonert of the web sra ptag-in may be configured, usin^ 
use different levels of gnmutoriiy in making the. response time decisions. As discussed above, client requests 
generally reference a particular executable component on an application server. For example, a URL such as 
"http-7/server,domain.com/abc.jsp" may reference a JavaServer Page™ component, -abcjap". In an exempiaiy 
system in which the "abc.jsp" component is replicated across three application servers. Application Server A, 
Application Server B, and Application Server C, the average response time, as seen from the time the request 
referencing the "abc.jsp- component is sent to the qipUcstion server to the time the request results are received 
fiom the application server, may be as foliaws: 

AFpfiGatianSavcrA: 0.7aee 
Application Server B: O^aec 
Usee 

In such a case, it may be advantageous to enable die load balancer component of the « 
referencing die "abcj^" conqxment to Applicadon Server B. In a 

- basis, where each request referencing a particular component is sent to the appUcation server 

BSL 

5 on a per-con^xment basis may benefit application performance for certain 
types of applicatioDS. However, for oflier applications, tracking such response-time information on a pe^ 
component basis may result in overhead that outweighs die benefits. Thus, the load balancer component of flie web 
server may also make decisions on a "per-serve.- basis. That is. d« determination of which application server «> 
send requests to is based on die average response time for an requests. It is noted d»t in one embodiment the per- 
server and perH»mpoaent method, may be cmiibined. so that administmtois mqr qiecify . P-ticutar set of 
components for which die k«I-balm«dng decisions are made based on a perHxm^^ 
made on a per^server basis for default eoaqioneiils. 

Figure 5 illustrates one embodiment of a web server client 300 with a web server plug-in 302 comprising a 
load balancer component 304 which distributes requests across an application server ctaster (appUcation savers 
308A - 308Q. As shown, the load balancer cemponmt 304 may maintain a table or Mat of response times 306. to 
be used in nuking load balancing decBicma ai 
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The client, e.g., the load balancing component of the web snrver phig-in. may also make load balancing 
decisions based on factors other than response times. For example, in one embodiment, administrators may assign 
a *\ireight" to each application server m a cluster, using an administradve tooL A weight may be assigned to each 
application server- based on the server's resources, suc^ as the number of CPUs, the memory capacity, etc. The 
S application server weights may then be used in various request disliibuticn algorithms, such that requests are 
distributed among the. application servers in pri^xntion to their weights. For exan^le, weights may be used, in a 
weighted round-robin algorithm or may be applied to enforce even distribution for certain types of requests, as 
d e scribed below. 

Figure 6 iOustratBS one embodiment of a ttreb server client 300 with a web server plug-in 302 con^ising a 
10 load balancer aanpoaatt 304 which distributes requests across an applicatimi server chister (i^UcatioB secvcts 
30gA-308C). As shown, a weight is aligned to each application server in dw cluster, and Aeweii^ arc used in 
a weighted load balancing algocidBB. 

Load Balancing DctemniBed by Application Server Load Batoncing Service 

IS Instead of leaving load balancing decisions to the client, based on such factos as mpmuK times and 

server virelgfats, in various embodiments the application servers themselves inay be lesponsMe fu distributing 
requesB among different conqniters in the spplication server chister. For exanqde. in flie Figioe 4 eninpte, tiw 
application server 230 conqniaes a load balancing service 222 that perfaims request load balancing. Figmc 7 
flhistrates a chister of application scrveia 320A - 3200 in which each app^aaiaa sjgvcr conaprises a load bslanri ag 

20 serviee330. 

The load balancing services of die application servers may share information to be used in deciding vAndi 
application server is best able to process a current request Onedassofinfonnationlhatinaybe &Gtoredinlofliis 
decision is refencd to as "Wver load criteria." Server load criteria includes varicnis types of infonnatiaD.tfiat may 
be indicative of how >isy" an application server cuirently is. sudi as die CPU load, die i^rat/outpm tale. de. 
25 Figure 8 ilfaismtes a table of exenqilaiy server load criteiia. Any of various odier factois aflecting server 
performance niay be considered In odier enibodinieBls. 

AnoOier class of information that, may be factored into load balancing decisions is referred to. as 
"application component perfoimance criteria". Application component perfoimance criteria includes infomiatiaa 
regarding die perfoimance of a particular application cranponent, e.g. a particular JavaServer Pages™ component 
30 Figure 9 illusnates a taWe of exoiqilaiy criteria that inayaireci application conqnii^ Forexani|de, 
Figure 9 iOuslrates a "CSched Results AvailabV eritdtioa. As discussed bekmr. in vaiioas e m bud ii iie n t i , die 
execution results of application components, such as JavaServer Pages'*** components, may he cached. . Keusiitg 
execution resute cached on a particular application server m^ result in Aster processing of a request 

Anodier exemplary cirtcrion listed in Figure 9 Is IMod Recently Executed". For some types of 
3S application components, distributing a request to the application server .that most recentiy ran the application 
component referenced by the request may resuh in faster processus since that application server may still have 
context infoimauon for the application conQKmem cached. 

Another exemplary criterioa listed in Figure 9 is Tewest Executicms". In some cases, it may be detirabk 
to distribute different types of requests evenly across all application servers in a cluster. Thus, the ap^ieatian 
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d by a request the fewest number of times may be chosen to 



Asy of various other factors regarding application conqmnent performance other than , those listed in 
Figure 9 may be used in other embodiments. 

5 Hgures 10- 12 illustrate an exemplary user interface of an administrative tool for adjusting load balancing 

factors such as those described above. Figure 10 ilhisirates a user interface screen for setting server load crimia 
values, such as those shown in the Figure 8 table. Administrators may adjust die weight tor eadi ftciar as 
appropriate, in order to maximize performance for a pwticular application server. 

Note Aat the server load criteria vahies may be adjusted separately for eadi application server, as desind. 

10 Figtire 11 ilhisirates a partial tree view of application servers in an aijplication server In Fig^ 11. a single 

an>licatian server name. "NASI", is shown, along wifli various appUcation co n a|io n enls tiiBt ran on tiie "NASI" 
appUcation server. For example, in tiie embodiment shown, various Enterprise JavaBeans™ tiutt nm oo 
•VASr server are shown under the "EJB" heading. The screens shown in Figures 10 and II may be coupled so 
that the 8«ver load criteria settings adjusted on Ae Figure 1 0 screen apply to the application server selected on die 

IS Figure 11 screen. 

Figure 12 illustrates a user interface screen for sen 
such as those shown in die Figure 9 taUe. Adnmisnatars x 



above. Hie "server load" vahie shown in die Ftgnie 12 screen may be a campoaitB vahie computed using die 
20 Figure 10 server load criteria vatoes. TTnis, the load balancing criteria for each particular application componeiit 
may be fme-tuned using a variety of factors, in order to achieve maximum perfonnance for a particular system or 
appUcatioa The user interface may of course allow defknlt load balancing criteria to be specified, may allow load 
balancing criteria for mult^le application conqxments or muhqile servers to be qwdfied or oopied, etc 
Note durt in Figures 10 and 12. "User-Defnied Criteria- is seketed in die 
25 at die top of die screens, so diat load balancing decisions are made by die application server toad balan^ 
services. The user interlace may also allow die adminisirator to specify diat load balancing deci^ 
die "H^-t, e*. die web server phig-in. as described above widi reference to Figures S and 6. by selecting a different 
option in dtis field. 

Refeiring again to Figuie 7, die figure iflustrates diat the load balancing services 330 in each appUcation 
30 server 320 may communicate witii die load bakmcing services of odier appUcation servers in die chister in Older to 
share infoimaticm, such as the server load criteria and application con^xjncut perfonnance criteria described above. 
In one embodiment, die load batandng services commuaicaie using standard User Dstagnm Protocol (UOP) 



In one embodiment, intervals for both Inoadcasting and updating load balancing information may be set 
usmg an administrative tool Figuie 13 ilhistrates one embodiment of a user mtcrface screen for setting broadcast 
and update intervals. The "Base BroadcastA^te Interval" field refers to a base mterval at whidi die load 
balancing service "wakes up" to broadcast informaticHi for its respective application server to die load balancing 
services of odier appUcation servers, to check to see whedier any updated information was received from odior hiad 
balancing services, and to update die load balancing mforrnationwidi any received iqfdatet TTie ol 
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shown in Figure 13 are relative to the base broadcastAipdate interval. For exatnple, the "Application Component 
Criteria" broadcast interval is two times the base interval, so that application component performance infomuticm 
is broadcast every other time the load balancing service wakes up. Note that performance information for a given 
application component may be exchanged only between application servers hosting that application coinponent, in 
S Older to avoid inmecessaiynetwatk-trafiBc. 

Figure 13 also illustrates fields for setting tlie broadcast intenral server load infoimatioB, and ibe update 
intervals for infomiaticni described above, such as the server load value, CPU load. Disk Input/Output, Memoiy 
Thradi, and Nimiber of Requests Queued. By adjusting the various broadcast and update intervals appropriately 
for a given application or system, the optimum balance between fresh load balancing data, server update overhead, 

10 and networic traffic may be achieved. 

The information shared among applicaticm server load balancing services may be used to dynamically 
route a request received fiom a client to dw *1)estr application server for processing die icquesL As discussed 
above, each client request may reference a particular qjplication compcmem. The decision as to wliicli applicatioa 
server processes a request is preferaibly voMde based on thie stored infonnation icgarding ibe particubr appfiealian 

15 component. Thus, at any given time, the *%esr applicatian server for processing a tequen may depend on Ae . 
particular application component that die request references, depending on how the server load criteria and 
^plication con^onent performance criteria are chosen, as described above. 

If the load balancing service of die application server diat initially receives ■ request fiom a cbeat 
determines dwt another application servo- is cimtently better aUe to process die request, dien the request xaay be 

20 rediicciBd to the other application server. As shown in the Kgure 13 user interfaoe, adminisMlors may specify a 
T mi»h«.mi nnmbCT of Inis". Le^ the maxirmnn inmiber of times that a request may be rednecied before it 
processed by die application server that last received due request. The hop nuniber nnqr be iqidaled in die request 
informatibn each time die request is redirected. As die processed request is passed bade to dw clieBl, die wdi 
server phig>in, the client may record the application server that ultimately satisfied die. request; so that a similar 

25 future request would then be sem by the diem directly to diat application server. 

"Sticky" Load BahnduK 

Administiatois may maik certain appUcatioii coaqpnients for "stidtjT load baludiw. meaning diat 
requests issued widiin dK context of a particular session that reference that ai^lication componem aic dl pr 

30 by the andicatita ccnqionent instance running on the same applicaticm server. Some application cu iinK M i e nls may . 
need to be marked for sticky load bahadng, especially if the components rely on session information diat cannot 
be distributed across application servers. Such situations may arise, for exanqile. if an application is originally 
written to run on one computer and is then ported to a distributed application server cluster cnvnonment. 

As an exanqiile of sticky load bdancing, suppc»e that an application conqionent called "ShopCarf is 

35 duplicated acroa two application servers. Server A and Server B, for load balancing. If a &at client, Oieal 1 
petfonns a request referencing the ShopCart component, dien the ShopCart instance running on eidier Server A or 
Server B may be chosen to process the request, depending on the outcome of die load bdandng decisions described 
above. Suppose that the Server A ShopCart instance processes the requoL Then, if the Sht^Cart component is a 
conqmnent marked as requiring sticky load balancing, aiiy further requests issued by Client 1 that referenee the 
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SbopCart component win also be processed by the Server A ShopCart consent, regardless of the other load 
balancing criteria. Reqnesis by oflwr clients referencing the ShopCait ciwnponent may of comse be processed on 
odier serveis, e.g, on Server B, but then those requests too wooW "stick" to the application component instance 
where they were first processed. 

Figure 14 illustrates an exemplary user interface of a tool for enabling administrators to specify sticky load 
balancing for certain application components. Figure 14 illustrates a group of application components which, for 
exan^le, may be dispbyed 1^ navigating through a hioarchy tree such as shown in Figuic II, The "SHOy LB" 
cohmm of die user interface has a che«dd>ax allowing sticky load latendng to be tomed on for particalur 



AKhcmgh some existing application servfer systems suppoit sticky load balancii«. Ok information required 
to determine the comet application server Aat diould receive a given sticky request is often maintained on die 
server side. This may result in flie cliem conqputer sending a sticky request to a fust application server which diea 
redirects the request to a second appMcatioD server that should process the sticky requesL To overcome this 
inefficiency, the client convuter(s) may instead be operable to maintain infomiatiaB regarding sticky icquestt so 
that requests are sent directly to the correct application server. 

g stickiness may be made using naimil load 
balancing metiiods, audi as those described above. At any given time, these load balancing methods may 
determine thai a particular application server is the tesf server to process a request Thus, it may be possible fliat 
a particular application server receives a large batch of initial requests referencing stidgr convonents. Since cad 
session tiiat sem an initial sticky request to the plication server is then bound to fliat a i p plica ti oB server te 
subsequent requests, die resuh may be a decrease in application perfiarmance am dw long ten 

Thns, the system may track information regarding the number of sticky reqoesia dial are currently bound 
T and may fnce die sticky requests to be distributed rongUy eva^y. la one cmbodinwat, 
r, such as described above, and dK atidgr iequesla mqr 



Gtacefiil Distributkm 

Some exBting qtplication server load balancing systems use a "winaer-t*ke-alP aUatqar. in wWdl all 
i nfif.rA.g wqnerts at any given time are assigned to die cateulatcd liesT applicatioa acrvcr. However, oqieiienee 
in die apidicaliim server field ha« shown diat die resuk of such a strategy may be cydic 
given time, one appBcation server may be under a heavy load, white odierserveia are mosfly idle. Hiisproblem 
mqr arise in part fiom kad balanditg infoimation being thared at peiiodk Intervals, 

Thus, in varioiB embodimems, "giacefiiT load balancing mediods may be utilized, in which die liest" 
application server at a given time moment or interval, as defined by criteria such as described above, is assigned die 
largest number of incoming requests, while odier qiplication servers. «» a subset of die odier application serven, 
are snU assigned some of the incoming requests. Sudi giacefiil load balancing may be perfoimcd using aigr of 
various mediods. As a smqile example, a weighted random distribution algoridun may be used. For example, for a 
chister of application servos of size L, a random number between I and L may be generated, where the generated 
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number designates the number of the application server to assign the request to. and where 1 represents the cuneot 
"best" application server to process the request and L represents the application server at the other end of the 
spectrum. Thus, the random number is generated in a weighted manner, such that the probability of choosing a 
server number diminishes going from 1 to L. The resulting request distribution pattern may then appear similar to a 

5 y «= 1/x graph pattern. 

This type of graceful request distribution may be applied at various levdls, depending on a particular 
application or system. For cxan^le, as described above, one general load balancing tpptofch that may be used is 
to leave the distribution decision to the client, e.g., hy tracking the nspiaat times as seen fiima ea^ ^Ucation 
saver. - Thus the client, e.g., the web saver plug-in, may rank the application serverc by their response tinaes and 

10 "gracefully" distribute requests among the application servers, thus helping to mainiain an evea woik load among 
the application servers at all times. On the other band, if load balancing decisions arc made by the load balanciiig 
services of the application servers diemselves, as described above, dien these load balancing services may employ « 
type of gracefiil distribution algoridiiii. 

IS Request Faflowr 

As described above, requests may be fandcered from a client sndi as a web server to aa applicatian aotver. 
In some instances, requests may tail, e.g., doe to a lost connection b etween the client and Ae tppUaitiaa server, an 
applicatiMi server failnre, etc Depending on the conmsunication protocol used to perfor m the request, requests 
may time out after a certain time period.' For exanqde, a TCP/IP-based, request inay timeout after a ctmfigurable 

20 time period. Tbe timeout time period may or may not be configurable, depending on the environment, sudi as die 
particular operating system. Note that the typical default timeout period may be brjge, e.g. 30 minutes. If a request 
fails, e.g. due to a server power failure, odier requests may be fcoeed to wait while die icquestiiv doead waits for a 
reqioase dnt win never come. 

Figure 15 is a flowchart diagram iDustrating one embodnnent oT a mediod diat may overcome this 

25 ^obkm. In step 470, the client computer seiids a request to an application server using a custom wire-lewd 
communication protocoL The use of such a protocol may enable the client conq>nter to detect and recover from 
failed requests, as described beiow. Note that this custom protocol may be iirqslemented as a protocol using varioas 
standard commum'cation protocols, sudi as d» TCP/IP protocoL 

In one embodiment, each request is performed by a separate thread ruiming m the client computer. In st^ 

30 472, the requesting thread sleeps, using standard <^>etating system tedmiques. 

As Aawn in stqi 474, the le q ue s ting thread itay periodically wake up to poll die mp^plOaaaoa server fiir 
infomntion regarding die status of the request. The time interval for whldi the requesting duead sleq» between 
performmg these polliiig operations niay be configurable by system adminismnns via a provided user interftoe. la 
one embodiment, the requesting thread may poll die application server by sending a User Datagram Protocol tUDP) 

35 message comprising information identifying the request to tbe application server. For example, each request sent to 
the application server may conq>rise a request ID enabling both the client counter and the application server to 
track the request Upon receiving the UDP message, the application server is operable to use the request 
information to determine the status of the identified request and inform the requesting thread of die request status. 
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In step 476, the requesting thread detennines whether a respcmse to the poll message wm received fhan 
the application server. For example, the requesting thread may simply wait for a response for a pre-set, relatively 
dioit time intervaL 

If a responsfe to the poll message is received, then m step 478. the requesting thread analyzes the resp«Hiae 
to determine the current stanis of the request, as informed by the application server. If the request is cunenOy being 
processed by the appKcation server, then the requesting thread may simply return to sleep, as shown in stxp 480. 
Note that this check can flms not only detect faOed requests, but may also enable Ae application server to process 
s that take a lot irf time to process and that would result m request timeouts if si 



If die request is not cunen^ being processed by *e application server, Oen the request ftiled for some 
reason, e.g., due to a broken network connection, an application server error, etc. As shown in step 482, die 
requesting thread may then re-send the request and iben re-perform steps 472 - 488. The requesting thread may be 
operable to aneirqjt to send the request to the same appUcatitm server a certain Bumber of times before conchiding 
that requests to that application server are &ilii« for some reason and then atienqiting to send die request to a 
different applicatiMi server, if the application server is part of an applicadon server chisler. 

If no response to the poD message was received in step 476, then in step 484, the requesting diread may 
send the request to anotha qiplication server, if die lOTKcation server is part of an ^^pBcatio^ 

Hk client computer preferably maintains information regarding die cunent state of each application server 
in die chister. In aep 486, die application server diat <Ud not reply to die polling message may be marked aa 
"offline" so that further requests will not be seat to that application server. 

As shown in step 488. die client conpnter may be operable to periodically poll die fiiled applicatiiia 
server to detemanewhedier die application senrer is online again. For exan^le, die cilient computer may nm « 
thread diat maintains die applicati<m server status information and periodically polto die appKcato 
as being offline^ If ,o,dien die application server status infoimation may be updated so diat die ^ 

Pass Reloading 

In various embodiments, an applicatioa server may allow sc 
Servktt'" and JavaServer Pages™, to be dynamically reloaded while die i 
.dminisiratois to make changes to an application widwnt restarting. Having to si 
course, a serious problem in many rituations. As described below, adminisiiaton may specify wUch chisei wWeh 
are to be considered *>rersionabie^ or dynamkally rdoadaifale. 

A veisioning scheme is described widi the foUowiiv deagnpoims: 

• Not an classy are versioned by defauh. A distinction is made between "versionable" and "non-versionaMe" 
classes. As described above, versioning eUeses bydefauh often suffers from various drawbacks. 

• Version all major components - If client's classes are "Known" (see definition betow), dien versioning wiO 
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• User Configurable - For ihosc client classes that are noi "Known", the client may pcifoim additional steps 
during deployment time to set up environmental variables. Users can then explicitly spediy additional 
appUcation-level classes that should be versionablc 

• Interfaces are preferably not versioned to avoid runtime conflicts that may be caused by dynamically updating 
5 interfaces. 

• The user may designate some classes as system classes. System classes preferably arc not vemoned. Ceitam 
classes may be designatied as system classes by default 

Under the versioning scheme described herein, a user may control class vexsicoiability/^IoadAility by 
10 xau^ the following environment entries, which may be impfemented as legisny entries, A user inleifitce may be 
provided for managing these settings. 

• GX_ALL_VERSIONABLE 

A non-zero vahie for this entry causes all classes to be considered versionaUe. The default vahw is zen. This 
IS entry may be used for backward con^tibilitywidiodier systems. 

• GX_VERS10NABLE 

Tins endy con^nses a semicoIoD-dcIimiied list of classes that are to be considered by the system as veisiaadik 
classes. Bydefiiilt,dielistisem|iQr- 

20 

• GX_VERSIONABLE_IF.EXTENDS 

This entry con^iises a semicolon-delimited list of classes. If a user's class extends a class in this list, then te 
user's class is coosideied to be. versionable. The default class list contains the javmuervlet.GcneicieSavlet and 
javax.servletJltq>ServIet dasses. Users can anpend additiqsial dasses to 

25 

• GX_VERSIONABlX_lF_IMPIJEMENTS 

This entry con^irises a semicolonrdelimited list of interfaces. If a class implements an intoftce in diis list, <ben die 
class is considered to be versionable. The defauh interface list contains the javax jefVletSenrlet intefftee. Uaen 
(£an append additional interfaces to this lisL . ' 

30 

• GXjrASKMANAGERPERlOD 

A timed thread wakes np periodically to chedE for any classes that inay need to be reloaded. If a user modifies • 
versionable r'-««. the thread may instantiate a new dassloader to dynamically reload the modified class. The sleep 
time period for the dvead may he set by settii« the vahie erf* the GX_TAiSKMANAGER_PElU(» icgislry entiy. 
35 TTm default vahie for (he GX_TASKMANAGER.PERIOD entiy is "KT seeonds. 
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Known aa»es 

The class loader may deteitnine ■whether a class that needs to be versioned is "known" based on its 
inheritance tree. The class loader checks for the class's super classes and implemented interfaces to determine 
whether they are in the GX_VERSIONABLE_lF_EXTENDS or GX_VERSI0NABLE_IF_IMPI:EMENTS lists. 
5 respectively. If there is a match, then the derived class is censidered "known". 

This system works particularly weU in situatioDS ^»*ere aU or most classes dwt need to be nmtnne- 
versioned are subctosses of a relatively small set of super chases. For example, in die case of servlets. all servlet 
classes diat are versionaUe may be subclasses of die javax-servleLGenericServlet or j«vax.servletHttpServle^ or 
diey XBxy aU implement die javaxjervlet.Servlei xntei&ce. 
10 In one embodiment. JSP fflei « version^* by deitolt Tliey can e^ 

inheritance, but 1^ dieir file name extension of 

For any given ckss name diat die dassloader is asked to check, die classloader may locate die class fik in 
die nie system, dien parse the cUssfOe in order to identify its immediate supercUss as well as tdl d^ 
implemented by die class. It is importam .o note d«t during die check, die class loader any only ex«nine die 
15 classffle in die file system to determine versionabiHty and may not actually load die class into d« sysnan in orfer 
loexamineit. Due lo die cache stickiness of die JVM concerning loaded chases, pievioiis experi 
d»titis«s»dly.b«Iide.lolo«i.cl.astodetennii«d*version.bility«fi«. Ttos d« --nonMl- way to n-ke 
one's class versionable is to extend^mplement diose classes specified in die above-mendc 



Uijuine a Wami -f '"^'"^ *i^'K,inf^ VTon-versionable OassM 

One potential problem occurs when an olgect diat is t 
another object whose class is versionable. In order to detect po 



wrialBed, a snb-class of die sncam class is instantiated. In dns 
( dist is being serialized. If such a class is determined to be 
-verrionable- (as defined hyfterfH«re-mentionedndes).d« system may issue or log a w«Bi^ Hus detecticn 



Aiv cache widiin die system whidi may cont»n . versiot-We dasse. (eg, EJB container, seivlel.. JSPs) mqr 
face so diat a class can be purged fiom die cache on a per^hMS basis. e«, Iqr "pecifying d^ 
_ .purge. EadiconT««»t<h«tpo6bversionabteoldeeisdiouldprovi^ 
, to infonn d«m du« d« ch« verrions for diose objects have chM«ed. «id d«t die port 
For exan^le. an application server Java"* Servlet tnnner 



b one embodiment, diere are diree diflierent class loaders woridng inside die system at any given ti 
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• The Pnmordial Classloader (PCL) - used to loaA any core classes and any native code usin| 
classes 

• Engine QassLoader (£CL) - A classloader (iHore precisely a series of ei 
veisionable classes 

5 • Non Versicnable Classloaders (NVCL) - A classloader used to load all non-veisionable classes. There is oaiy 
one such classloader, which is prcferaUy nevo- replaced. 

A loadClassO call may first determine whether the class in question a versionaUe or not, and then use die 
appropiute clas>k»derlo load Ae dus. 

10 

Figures 16-17: Veisionnig Flowcharts 

Figure 16 is a flowchart diagram ilhistrating one enibodiinent of a mediod for dynsmicaDy discovenng 
and reloading classes, based on the descriptions above. 

In step 400 of Figure 16, a timed thread wakes up to check for modified classes. It is noted diat it may 

15 onfy be necessary to chedc for dianges in certain classes, since classes are not y e is iou ed fay default In one 
enobodtment, the list of ver»anabk classes may be determined once, e.g. using the method shown in dwFtgiBe 17 
flowtdunt, and die list may be reused by the timed doead eadi time the dnead wdces np. If an admi ni st m oe 
changes die vernonability settiitgs, the list may be updated. EadidassmtheHstmaybedieclcedformo^BficatiaM 
in aiiy way appropriate for a particular environmeot. For exan^de, the .applicatiao server may record dw date and 

20 time of the class fQe when the class Is fust loaded and may check to determine wbedier the file has since been 



As shown in step 404, if no modified versionable classes are found, the duread may simply return to sbep^ 
If aw or mom modified classes are found, dien steps 406 -.410 inqr be performed lor eadi mbdifM 
In step 406, a new clas sl oade r is instantiaiBd. 

In stq> 408. dw classloader instantiated in step 406 is used to reload die modified ciasi. 
In step 410, the modified class may be purged fiiom any caches maintained by <he qiplieatian server.. As - 
described above, ai^ af^Iication server conqxments that maintain caches may provide interfaces for pwging ■ 



It is noted that Figure 16 represents one embodiment of a method for d y na mic a ll y reloading classes, and 
30 various steps may be added, omitted, combined, modified, reordered, etc. For exanqile^ in some euviiuuiueati it 
may not be necessary to instantiate a new classloader for eadi class to be reloaded. 

Figure 17 is a flowchart diagram illustiatii}g cme enibodiinent of a iiiethod for detenniiung 
° is versionable. that is whether the class should be dynamically reloaded when m odified. 

In step 420 of Figure 17. it is determined ^Rdiether die classname is listed in the GX_VERSI(»IABLE list 
35 (described above). If so. then the class is versionaWe. 

In stqi 422, it is determined whether one or nunc of die class's superclasses are listed in die 
GX.VERS10NABLEJF_EXTENDS list (described above). If so, then the class is versionable. 
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In step 424, it » detennined wheiher one or more of the interfaces implemented by the class are listed in 
the GX_VERS10NABLE_IF_»4PLEMENTS list (described above). If so, then the ctass is versionabk. 
Otherwise, the chiss may not be veisionable. Modifications made to non-veisionable classes may be ignored wUle 



It is noted that Figure 17 Represents one embodiment of a method for detennining wheOier a cluB is 
veisionable. and various steps may be added, omitted, combined, modified, reordered, etc. For example. «ep» 
- 422 may be perfcHined in any Older desired. 

It is noted that an application server utilizing the methods described above willi nference to Figures 16 
s to be veisionable by ddTsuh. Hms helping to enfoiee 



bqiecifiedinsicp 



Atomic Qass-Loading 

It is often desirable to update a set of classes aiomically. i.e. to have aU dynamic reloading changes foi 
each class in the set take effea at the same time. Withmrt an ability to peifoim atomic 
15 result when classes are dynanacally reloaded. 

Figure 1 8 is a flowchart diagram iUustrating one embodiment of a method Ifar 
loading. Asdiowninsiq>440.anadministtat«mayspecilyasetofclas8filestobeti 
example, the application server may provide a user interlace for managing i 
development environment to the runtime system. This user interface may « 
20 a dass bundle. In one embodiment, a component referred to aj 

In step 442, the admimstratof recpiests the appKcalion server to deploy the class b 

440, eg., using the user interftce described abowe. 

In response to the administrtinr's request in step 442, the deployer manager may obtaim a 

„ the -dirtyClassListLodc- in step 444. The dirvOasdistLpdc n^ 
25 ways. e.g, as a semaphore. Tbe timed duead described above that dynamically discovers an. 

versionable cUsses may also require the dinyOasslistl^*. TTins. wWle the deplqyer msnager holds the 
dirtyCHassLislLock, the timed thread may not proceed. 

After obtaining the dixtyClassListLock. the deptoyer manage copies all chw files in the bundle to their 
appropriate runtime locations in flie fBe jqrstem in step 446. 
30 The deptoyer manager then releases the dirtyClassListLock in step 448. 

Asshowninstep450,fl«timedth««lc«thearesuineit,nonnri«3«ckf«iaod^ T^Ol 

dw WW classes firom the bundle are p 



JavaServcr Pages™ CacMag 

Ibis section provides an overview of JavaServer Pages™ (JSP) technology and de 
and method for JSP cowp^ responses. JavaServer Pages™ (JSP) is a Java™ phitfom technology for buildhig 
appUcations streaming dyn-niccontemsudi a. HTML, Dinm.XHTm and XML JavaServer Pages is a 
Standard Extension that is defmed on top of the Servtet Suindaid Extension. JSP 1.0 Uses the classes firom Java 
Seivlet 2.1 specification. For more information on JavaServer Pages™, pkase refer to the Ji 
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Specification, Version I.O, available from Sun Microsystems. Inc. For more infoimation on Java servlets, please 
refer to the Java Servlet 2.1 Specification, available from Sun Microsystems, Inc. 

A JSP component is a text-based document that describes how to process a request to create a response. 
The description intermixes template data with some dynamic actions and leverages on the Java"* PlatfomL In 
general, a JSP component uses some data sent to the server in a cliem request to interact with information aheady 
Stored on the server, and then dynamically creates some c<mtent which is then sent back to the client The content 
can be wganized in some standard format, such as HTML, DHTiO^ XHTML. XML, elc^ or in itaue ad-hoc 
structured text ftnmat, not at alL The followiog segment Slustrates a simpie exuyle of a JSP conponeat: 



<% if (Calendar.gelInstance0.get(Calendar.AM_PM) CBlendarj\M) {%> 

Oood MonuB^ 

<%}ebe(90 

Good Afteiuoua 

<%} %> 



The exan^e above shows a response page, ^ich is intended to displ)^ eiAcr 'tsood Moniii«'* or "Qood 
afternoon" depending on the moment when the request is received. Tlie page itself cooluns aevcnl fixed «»"ipi««i« 
text sections, and some JSP elements enclosed in %>** brackett. 

AJSPconqionentnuybe liandledinaiiplkationservccsby various types of JSP engines. For example, in 
one enibodnneai, the Java Server procos 204 shown in Figure 3 may manage or act as die JSP engine. The JSP 
engine deliven requests from a client to a JSP c o iu p ouc at and ieaponses from the JSP conpaaeiit to the '•fs^n t TIk. 
semantic model undetlyiag JSP components it diat of a Servlet: a JSP contponenl describea how to Greats a ■ 
re^nse object from a request object for a given protocol, possibly creating and/or using in Ute process some odw 



All JSP engines must support HTTP as a protocol for requests and responses, but an engine may also 
support additional requestAresponse protocols. The defaub request and response objects are of type 
HtqiServletRequest and HtqiServleiResponse, reflectively. A JSP ccm^Mment may also indicate how sane evcatt 
are to be handled. Ill JSP 1. a only init and desMy events can be desciibed: the &st time a leqoM 
JSP conqMmem a jqdni<) mediod, if pnHHmt, win be caUed to prqiare dw page. Similaily, a J^ e^^ 
dw resources used by a JSP conqmnent at any time that a request is not being serviced by Ae JSP conycnent by 
invoking first its ^pDestroyO mediod: this is the saoK ltt<^«yde as Oat of 

JSP con^wnents are often implemented using a JSP translatitm phase that is done only once, followed by 
some request processing phase that is done once per request. The translation phase usually creates a class that 
implements the javax.savlet.Servlet interface. Hie translation of a J^ source page into a conesponding Java 
implementation class file by a JSP engine on occur at any time between initial deployment of the JSP conq>onent 
into the nmtime environment of a JSP engine, and the receqn and processing of a client request for the target JSP 
componenL A JSP component contains some declarations, some fixed ten^Iate data, some tpoliaps netted) action 
instances, and sonw scr^iting dements. When a request is deUvered to a JSP conqxmenl. an these pieces are used t^ 
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cieate a response object that is then retained to the client. Usually, the most important part of this response object is 



A JSP coroponem can create and/or access some Java objects when processing a request The JSP 
specification indicates that some objects are created mipliciay, perhaps as a result of a directive; other objects are 
aeated explicitly through actions; objects can also be created directly using scripting code, althoue^ Oiis is teas 
1. The created objects have a scope attribute defining where there is a reference to the object and when Alt 



The created objects may also be visiUe directly to fhe soi^ptaig elements dirough soine saqiting-levd 
variables (see Section 1.4 J. "Olgects and Variables). Each action and declaration ddines. as put of its senanliGS. 
what dl>jects it defines, with what scope attiibBie, and wbeto they are avai^ ObjeeH 
are always created within some ISP con^jonent instance that is responding to some leqpiest object JSP defines 



- page - Objects with page scope are accessible only within the page where they are crested. All reliseBcea to ai 
M, object Shan be released after the response is sent hack to the client from the JSP c 

e else. References to olgects wifli page scope are stoied in die pagecontezt clijeet 



b request scope aie accessiblie from pages processing the same request where diey were 
1 An references to the olgeet ahaO be released after flie request is processed; in particular, if die request is 
forwarded to a resonice in the same runtinie, the olaect is stin reachable. lUfew^ 




e created. It is not legal to defme an olgect with sessiim 1 
. AD references to the olgect Shan be released after the associated • 
oj^jecis with session scope are stored in the session object assod^ 



- appUcation - Objects widi application xopc are accessible from pages processing r 
application as they one in »drich they were created. AH references to the object Shan be released 

IS the ServletContext Objects with application scope can be defined (and reached) from pages 



References to olgects wiA application scope ase stored in tte spplieatloa ol^ 
usodated with a page activation. A name should refer to a nniqi* oldect at aD poinis in the exeoitioo. ix. aU 4e 
different scopes reany should bdiave as a singfc name n>ace. A JSP invIei»>entation niay or n« 



Fixed Template Data 

Fixed template data is used to describe those pieces that are to be used v 
input to JSP actions. For example, if the JSP component is creating a presentation in HTML of a list of; say. books 
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that match some search conditions, the tenqilate data may include things like the <vX>, </v>, and something lil 
<Ii>The following book... , 

This fixed template data is written (m lexical order) unchanged onto the ou^ stream (referenced by «l 
inqilicit out variable) of the response to the requesting cUeHt 



P elements can be directives or actions. Directives provide global information that is conceptually valid 
It of any specific request received by the JSP con^onenL For example, a directive can be used to 
indicate the scripting language to use in a JSP conq»onenL Actions may. and often will, depend on the deuils of the 
10 specific request received by the JSP component If a JSP is implemented using a cenpaer or traoslataar, Oe 
directives can be seen as providing informatitai for the con^nlatioii/traiislation phase, while m 
fOT die subsequent request processing phase. An action may create some objects and may n 



Directive elements have a syntax of the fonn 
15 <%@ directive ...%> 

Theie is also an alternative syntax Hat follows the XMDL synWL 

Action elements follow the syntn of XML elements. Le. have a start tag. • body ai 




X vahie" ../> 

A JSP element has an eleniem type describing itt tag naiiie, its valid attributes and ilB 
semantics: we teiisr to the ope by its tag name. 

AndicationsandServletConlestt 

In JSP 1.0 (and Serirlet 2 J) an HTTP protocol api^caiion is idemiM 
mapped to the resouices therein. JSP 1 .0 does not include a mechanism to indicate that a given URL denotes a JSP 
,H ffmp««.t, although every JSP implementation wiU likely have such mechanism. For cxampte, JSPs may be 
identified by a ".jsp" fde extension, hi most JSP inqilemenutions. a JSP conqponent is Iranqnrently translated hno 
a Servlet class file through a process involving a Java™ compiler. 

The URL set described above is associated. 1^ die ^ etigine (or Scrvlct nmtime enviranmait) wiA • 



35 



unique instance of a javaxjervletServktOnrtext Soviets and JSPs in the same application can si 
sad diey can share global application state by sharing objects via die SeivletContext setAttribotiia getAttributeQ 
and lemoveAtiributeO methods. We assume that the information that a JSP component uses directly is all 
accessible from its corresponding ServletConiexL 

Each client (connectiori) may be assigned a session (j8vax.servlet.http JlttpSession) uniquely identifying IL 
Servlets and JSPs in the same "application" may share global session dependent state by sharing objects via die 
40 Ht^iSession putVahieQ. getVahieQ and removeVahieQ medmds. Care must be taken when sharing/manipulating 
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such state between JSPs and/or Servlets since two or more threads of execution nay be simultaneously active 
within Servlets and/or JSPi, thus propel synchronization of access to such shared state is lequiied at aU times to 
avoid unpredictable behavioB. Note that sessions may be invalidated or expire at any time. JSPs and Servlets 
handliflg the same jaVax^let-ServklRequest may pass shared state using the ServktRequesl setAttributeQ. 
gelAtnribnteO «nd «t«»*«AttribnteO meAods. 



A typical implementation works by associating with the URL denoting the JSP a JSPEngineServleL This 
JSPEngineServlet is responsible for determining if there aheady exists a JSP component impIemenlatioD dsss; if 
,„,» it win create . Servkt source description implementing the JSP componem. compile it into some bytecodes and 
thenlo«lthemvi..Cl.ssI^instance;mostlikelynevertonching.hef^ Once the JSP component 

located, the JSPEngineServlet win perfonn the usual Servlet xnitianzatiim and wiD deliver 
TO«ived to the instance. The JSPEngineServlet Servlet is instantiaied in • SetvletContejct diit 
n^nesents dK original JSP olgecL 

Tgpp««poiiseCadiin8 .«» ^ , 

This section describes how response aching may be enabled fa a system impiemenlins JSP tedmoloKy. 
Alfl«>ugh one use of JSP is to create dymmncieqwsndi a. dyn«niewd, pages fa di.piy.it ^ 
.ppreciatedtha»responsee«adngm.ybede«iibkinm.«ysito.,ioas.Forex«nple.^^ 
«ych««^ only once «ih«n. and dms. response creaiedtothe data codd be e«*ed««l«^^ 

rotoin^nove die perfonnanceofrunning compoHte JSPs. ttal is JSP files winch 



indnde other JSPs. 

Fox each JSP component, the criteria for reusing a cached version of die lespoise mqr be set. by 
inch.di«g.med.odcanintheJSPlile.s»ch.."setCacheCriteri.O". The se,C«d«C«.e«i.O ««*od m-y be 
overloaded to anow for various argmnents to be passed in. In one embodiment d« se,C«*.Oi.eri.O - 
conqwises the foUowing signature varianii: 

seiCacfaeCriieriaCint sees) 

wtere the W parameter indicates fl« numbei of seconds for whid» fl« cached response shouU 
vaM. lndri.v.ri.«tt.nootbercriteri.arespedfied. Thu^ d« JSP response is m«onditiondly a»hed. IfWi. 
set to 0. die cache may be flushed. 

setCacheCriteria<int sees. String criteria) 

where d« W parameter is d« «m« as described above, and d« -criteria- par«nettr spedlies fl« ai^ 
indeterminingwhed,erornotd«cachedresponsemaybeusedtos.tisfy. request Cadnng criteria are d»cussed 

in more detail bdDW. 



setCadieCriteiia(iiit sees, int size. Siring critem) 
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where the 'sees* and 'criteria' parameieis are the same as described above, and <he 'size* parameter specifies the 
size of the buffer for the cached response. 

Caching Criteria 

The interface for calling JSPs is based on the interface javax-servlcLRequestDi^tchei. This imerface has 
two methods, forwardQ and inchideQ, where the forma acts Uke a redirect, Le. it can be called only once per 
request, whereas the latter can be called multiple times. For cxampit, a forward caU to T jqjf may look like: 

pubhc void serviceCHt^ServletRequest req. Htq>ScrvletResp«ise res) 

{ 



getServleiCi»text0.gcAeqBestDi8patcber("£jq>'% 
diqwicher Jbrward(rcq. Tea); 
) 

JSP convonents often accept and use argunents themseWes. Arguments to the JSP file can be passed as part of dw 
URL of the file, or in attributes using ServletRequest-setAttributeQ. these aigument names and vahies can be used 
to set caching criteria and to check whether a cached response can be used to satisfy a rcquesL 
Far exanq>le, in an include call to 'fjsp', argtmients *agc' and 'oc 

public void service(HttpServletRequest req. HtqjServletResponse tea) 
dirows ServletExceptioo, lOExceptian 

I 



getServletContext0.getRequestDii?»tcheK"fy«P'«We-«"); 
reqjetAtoibnteCoccupationVdocloiT; 
diqatcher jnclade(req, IBS); 

) 

Widiin the fjsp component, a SI 



<% setCacheCriteria (3600, -age>40 ft o 

to indicate that the response shouM be cached with an expiration time of 3600 seconds, and that die response may 
be used to satisiy any requests to ran the fjsp component with an 'age' aigumeM vahie of greater tan 40 and an 
'(xxupation' argument value of '^dodoi*'. 

Of course, the JSP component may contain numerous setCacheGriteriaO statements at different points in 
the JSP file, e.g. at differert branches within an "iT statement, each of which may set difierent caching criteria. 
Depending on the arguments passed into the JSP and other dynamic conditions, a paiticniar set of caching c 
may then be set for the reqionse cia 
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In the example above, the dispatcher may use the values of the *age' and 'occupation' arguments to 
detennine whether any cached JSP responses can be used to satisfy a request instead of re-running fbe JSP and re- 
generating a response from it For exan^le, a request to tjsp appearing as: 

5 Tes^etContentType("textfliOnl"); 

RequestDispatcher dispatdier- 

getServleiC&mext0.getRequestDispatcbei(Tjsp?age=39&occHpationFdoctoiT; 
disp8tdieriarwnd(Kq, icsk 

10 woidd not be satisfied by a le^ionse previously generated firom die £jsp JSP which had set caching oileiia widi 



15 because the age argunwit is not wifliinAe range qjecified as valid for this cached reapon 

request may be satisfied by a rcqxmse previously generated from the fjsp JSP which had set its caching e 



<% setCacheCriteria (3600, -age>35 A occupation-doctoO; 

Hence the cache may be checked before running a JSP, and if a valid cached response is found, then die dispatcher 



Acacbed JSP re^Kmsemiy be stored in various ways. In one enAodiment, « response is stored as a hyle 
anay (byteD in Java). Each cadied response may have an associated criteria set stored, indicating when die 

25 reqmnse is valid. The criteria may inchide an cqniation time, e* a time in seconds to consider die cached 
refuse valid. After this expiration time passes, die response may be removed from dw cache. Hie criteria may 
also inchide a set of constraints, where each constraint specifics a variable and indicates die valid vahws ^«*ii* die 
variable vahie must match in order to satisfy the cache criteria. As described above, a JSP reqxnse may set dwae 
cache criteria programmatically usmg a setCMheCriteriaQ statement For example, the SetCacheCateria (3600. 

30 **age>35 & occupationpdocteO s«»teni 



embodiments. difTerem types of consnaints may be specified, inchiding dw following types of 



(e.g, SetOcheCriieria (3600. "x*)) 
g that V must be present either as a paraneter or an attribate. 
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- X = vl I v2 1 - 1 wk (e.g, SetCactaeCriteria (3600, "x-docwrtmme'O) 

meaning that *x' must match one of the strings listed For each string, a regulai expression may be used, where V 
is said to maidi the string if it meett the regular expressirai criteria given. 

5 -x'' low -high (e.g,SctCaclieCriteria(3600, "x=20-50^) 

meaning that *x' must match a value in the range of low <^%<>= 

Various other types of constnints may also be specified, sudi as the use of mathematical "greater than/less ibaa" 
symbols, etc. for ensuring that an aigument falls widiin a certain range. Also,- constraints may be qiedfied baaed 
10 on dynamic user session data, such as the cuncnt value of a user's shopping cart, user demographic infonnatioii. 



Figure 19 - Flowchart 

Figute 19 is a flowchart diagram ilhistratiqg one embodiment of a method for enabliI^g JSP resp onse 
IS r^'-h^i, based on the above descriqpiian. In one embodiment, die JSP engine manages die {nooess .illustrated in 
F^nicI9;. 

In step 600 a request refercndqg a JSP component is received. The reiiucat may. foe example,, have an 
associated URL that references a JSP. The JSP engine may receive die request from another service or component 
running on the application server or directly from a client computer. 
20 In step 602 the JSP response cache is cbedced to detamine whether a response in the cache satirilea die 

request The JSP response cache may be implemented in any of various ways, and reqMDacs and Acb' associated 
criteria sets may be represented and stored in the cache in any of various ways. As noted above, in one 
e ia stared as a byte ainqr. 

n received alcnig with the JSP request may itelode vaiioas attribulo, 
25 audi as variable name value pairs. In step 602, these attributes may be compared against die criteria set for eadi 
cached raponse. The comparisons may be perfonned in various ways, depending on what typea of matdiing 
criteria are supported in a particular embodiment and how the criteria are stoscd. Tbe JSP ic^mnse cache ia 
preferably organized to enable an eflicient criteria-matching algorithm. For example, die cache may be orginfwd 
based on session context such as user ID or role, security context etc 
30 Insiq>604itisdeteimined«dKtfaeramatdiiiigcacfaedTeqK»sewasfowidinstq)60^ 

606 die cached response is immediately returned widMUt running the referenced CT. For example^ if lespoases ate 
stored as byte arrays, then the byte amy corresponding to the response whose criteria set maldied the request 
attributes may be retrieved and streamed back. 

If no matching cached response was found, then in step 608 the referenced JSP may be called. Tbe JSP 
35 engine then executes the JSP, using the amibutes included in the request. As described above, depending on die 
dynamic conditions of die execution, diifcrent SctCacbeCriieriaO method calls widi different arguments may be 
encotmtered during the JSP execution. 

In step 610 it is determined ■wbeOta tire JSP lespaasK should be cached. Tcr example, if no 
SetCacheCriteriaO mediod calls were encotmtered duriqg the execution of tbe JSP. then the response may not be 
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cached. Also, in various enibodnnents, the application servw nay enable admiiisiraioxs to utilize a i 
to specify for which application seiver components the output should be cached. This infonnation may also be 
chedcedinsteptilO. 

If the JSP response should not be cached, then the response may simply be retoroed in step 616, e^., by 
streaming back the response. 

If the JSP response should be cached, then in step 612 a response entry to represent the response may be 
created, and in step 614 the JSP response may be stored in the response enBy. As noted above, response entries 
nay be implemented many of various ways. As shown in step 612. the appropriate criteria set. ■» defined by the 
B of the SetQcheGiteriaO method calls encountered during the JSP execuAon may be associated with die 
r. Sole that, if mnWpfcSetCacheCriteriaO method calh are encounteied. then rnnh^ 
entries coweqHmding to the method calla may be aealBd. 

U rXted that Figure 19 represents one embodfanem of a method for enabling JSP response caching, and 
various steps may be added, omined, combined, modified, reordered, etc. For example, in one c mb odimrnt. • step 
may be added so that the JSP file referenced by the request is checked on the file system to deteimine wliedMr Oe 
fde has been modified since the JSP was loaded or since the associat.ii responses were cach^ If so. the associated 
responses may be flushed Ihim the cadie. and the JSP mv be reloaded and c*^ 



With the support described above, composite JSPs. that is JSP files wUch inchide ofl»er JSPs. can be 
efficiently in^lemented. Here may be one top-level frame, emitted either to a «nrlet or Ikom a JSP. wWeh 
issue, one or several RequestDispatcherinchMlecdU for other JSP file.. E«di of the inctoded JSP file, 

. Some of the« JSP file, may aheady have associated response, cacied. and odwimey 



For exanqile. here i. a 'compoK.jq)' ISP 



<K 8etCacheaiteria(l):%> 

<inML> 

<JBM3l> 

<tnLE>can|ioK (JSF)<amE> 
</HEJJ3> 
<BODY> 

<I2X3tannel 1</H2> 
<K 

RequestDispatcher diip - 

getServletC0ntod0.getReqaestDispaicJiei(-cl.jv"); 
diq>inchide(req^iest. lesponw); 
%> 

<H2>Channel 2<H2> 

*^isp = getServletContext0.getReqnestDispatdier("c2.jqi-); 
dispincludeCrequett, nspaaaeyi 



30 



Wd 01/13227 



PCTAJSOO/22055 



%> 

<BOI3Y> 
</HTML> 



<% setCadieCritenaClO); %> 
<U>Todiy„. 



and 'c2.jsp' appeals as 




Note diat ndtber 'c 1 Jsp' nor 'c2.jqi' amis complete HTML pages, bui zadwr snqipets dwreof. and diat caeh file hi 



A helper finctkm for incliidnig URb may be provided, so dial, for example, die above-listed *« 



<% setCacheCriteiiad): %> 
<ITIML> 



<TTn.E>compose (JSP)<miLE> 
<«EAD> 
<BODY> 
<H2» 
<% 

incl 
%> 

<94 



<BODY> 
<E1TML> 

instead of as the listing shown above. 



s of application servers, developers can create and use named events. The term 
event is widely used to refer to user interface actions, such as mouse clicks, that trigger 'Code. However, the events 
described in this section are ncM user iotoftce events. Radicr, an event is a named action or set of actions that may 
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off « ft » called ftom code, the «soci.ied.cdans occur. EveaB may be tngge«d .ync 




advmtageoiisly result in 

calkd in other ways, e.g., ~— ^ - . . ^ ..^ Hioe imy be s • 

between Attributes «Kl Actions of -.evem. ^""^"^^^^ 
«„eve«i.r«presentedby.sep««eV.lU«. Tbe evoU APln»y piovulc 



,^«,«ld/delete/«n«««»«— - ^ in a clus«. In one e«bodin«« of the 



^.«cribed-K««.nn.^len^li"ti«-«-y^^^^^ 
_«rvice.ev«..or.parti»lareven..n«ybe.n.^.^^^^^^ 



o have a cluster-wide scope, ao 
^ |« defined -Id rcgistcted for every sender in d« cluster that needs ther-^ 
.ttribuies specifying which application seiver the event 



Events may be registered on multiple applicanon 
tion, adding act 
»I may support I 
may be created from one application 



adding actions, gening attributes, etc. may o 
nanagcmeat across multiple > 
Hid then called from ano&er application w 
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Event API 

This section discusses one embodiment of an API for managing and using eveirts. 

To create a new event, use the fonowing piocedniK 
5 1. Obtain the event manager object calling getAppEvoHtO. Fbrexan^ 
lAppEvent eventMgr » getAppEveniO: 

2. Speciiy the characteristics of the new event by setting up an IValList object with a set of vahies. each one being 
one characteristic of the event The values required in this object vary depending on whether the event's action is to 

10 lun an appUcatioa cuimnaicnt, send an email, dCi 

3. Infoim the ai^licationserwoflhe new evail by calling x«gi«erEveBl(). 
For cx.axnp^ ihe following code sets up an event to send emaik 

15 

IValList eventOutput; 
TVaQList eventliqwt2 GX.CreateVaILisO: 
Stiiag evenfl4ame2 - lleportEvai^: 
// Add the RepwtAgent appevent naine lo Ae valliirt 
20 eventInpHt2jetValStiing(GXJ^JlEJCEYJ<AME.GX_AEJUE^ 
evGnirtame2); 

// Set Ae vpevent state to be enaUcd 

evcntlnput2^VaUnt(GX_AE_RE_KEY_STATE.<3X_AE_RE_KEY_STATE. 
GXJVE_RE_ESJ1j\G.GX_AEJ«E_EVENT_ENABLED); 
25 //Set the appevent time to be 06:00:00 his everyday 

eventlnput2«tValString(GX_AE_RE_KEY_TTME:GXJVE_RE_KEyjn^ 
-6K)K) •/•/•■); 

// Set the appeveat action 10 send e-nul IB 

// iepOIt @a <i II IP imiM 

30 eveniIi4ml2jetValSiiing(GX.AE_RE_KEY_MTOXa_AE_RE_KEY_Mro 
■mwit@acnie.com"); 

// The contem of a>e e-mail is in /tmp/repoit-file 
eventInput2^tVaIString( 

GX_AE_RE_KEY_MFILE.GX_AE_RE_KEY_MFILE. 
35 "/tmpfreport-file"): 

// The e-mail host nmning the SMTP server is maibvr 
eventlBpnt2^etVa]String( 

GX_AE_RE_KEY_MH0ST.GX_AE_RE_KEY_MHOST. 
"aailsvTJicmBXoai"): 

33 
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// The sender's e-mail address is admin@acme.coni 
eventInput2.setValStxii«( 

GX AE_RE_KEY_SADDR.GX_AE_RE_KEY_SADDR, 



5 //Register die event 

if (evei«MgrjegisterEvent(eventNanie2, eveiilliipiit2) 
!-GXESUCCESS) 



T>pially. an evert is triggeied at tine inten^te ^MA yoa specify when you create the event Y<m a 
also trigger theevenlrt«Vti««ftom«.de.-n«ev«rt«iII occws at its timed intervals alsa events that ( 
not have a timer arc triggered only when called from code. 



I. 01»iainflieevertinanager<rtqect»ve»n>>W8etA|q»EveB<)^^ Farenmide: 
lApfiEveat evertMgr- getAvpEvealO: 



20 2. Ifyoo wart to change aiqr of the characteristics 

desired diaracieristics. Use the same techniques as you < 



of the evert before running it. set up an IValList 



i wfaen setting up the event, tat include only i 



IValList nefwPiopB - CTCCiBatBVallirta 

newProp»^-lSlring(GX_AE_»E_KEY_NREQ.GX_AEJffi_KEV'J 



b trigger Ae event, can aetEvert( ). For exanvle 



s, or if you wart ton! 



35 To delete an event 

1. Obtain the event manager otgect fay calling getAi)pEvent( ). For 
lAppEvert evenAlgr- getAppEvertO: 

2. To delete the evert permanently. caU deleteEveBl( ). For eMi^rte: 
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eveniMgr.del«eEveiit("ReporiEveiir); 



pcTAJswwnoss 



Ten^orarily disaWing an evaa 

Disrfrtew evert ifyoudon:ty«rth to be triggered during a lemp^ For exaniple. you n 

not warn to generate reports during a conq«By hoIMay- 
To disable and enable an event: 

1. Obtain the event n»nager objea by calling getAi»pEvent( > For example: 
lAppEvent evertMgr - getAppEvealO; 

2. Tostqptteevemfioiniunningte«voiBrily,cdldi5ableEven<).Forex«n^^ 
eventMgr.disableEven«("ReportEveiar): 

3 WKn you warn &e event to be availabk again, can enableEvenl( ). For exani^ 



TO get infonnation about a particular ev««. can ^Eventt ,^ ^ 
a^contaioatheebaraeteristicaoftheevent. To got complete detaiU about .11 the currently d 
«B enmnEvcntX ). TOs method ««ras the IVaHist objects of dl the events known to 
can enumNextC ) to step Uuough the IV^ oldects renuned 

)me.hods are defined in the lAppEv«t tnter^ , me*od - defined « the 
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Exan^Ie: 

The following code genentes a repent of all registered evena. 

// Open /tmp/ieport-lik for writmg tlie report 

FfleOu^HitStream oufl^ - niiD: 
5 outFfle * new FneOii9wtStieaiii("/tmp/repoit-fiIe"): 

ObjectOu^tStream p = null; 

p = new ObjectOutputSiieani(aiilRle); 

// get appevcnt manager 

lAppEvent appEvent - getAppEven^: 
10 //Get the Emjnwrati<m object containing VaDLists for an 

// the registoed eventi 

lEmnnOlgcct enumOfaj - appEvenLenuniEveiinO; 
// Retneve the count of registered appevetils 
im mvm - emmObj-enuniCounlO: 
15 p.writeObject("Nun>ber of Registered EvadK "); 
p.writeInt(coimt); 
eiiuiiiC»g.cnim>Resei(<9: 
w]iifc(coiial>0){ 

lOtgect vlistOlg -= amnOy .omniNaflO; 
20 IVaUin vLiit - (IVanjst)vLisiOl9: 



vLisLgetValStiing(GX_AEJtEJCEYJ«Al^GX„AEJlEJCEy_NAME) 



p.wiiteOlrieet(iiaii»): 
25 p.wiileOlgecKnm"): 

/y Reaet the next item to retrieve fiwn ValLi« io be 

//dHS first oiw 



30 while ((name - vLisLgeiNextfCsyO) l-mlD { 
GXVALval; 

val - vList.getVaIByRei{nam^; 
p.writeObject(^\r): 
p.writeOi^iect(namBX 
35 p.writeObjeeK"-"): 

p.wTiteObject(vaLtoStringO): 

) 

) 




vList.resetPcsitionO'i// dxrougili all ibs 



lindKVallistaiid 
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Exanqile intoface for event API: 

interface IGXAppEventMgr '{ 
HRESULT CreatdEvenl( 
[in] LPSTRpEventName, 
lout] IGXAppEventObj ••appeventObj 

y, 

HRESULT RegisterEveiil( 

[in] IGXAppEventOlg' appEventOlg 

)•. 

HREStILTGetEveiil( 

[in] LFSTKpEventName. 

[out] lGXAp|«venlOI>i ••pAppEvem 

y, 

HRESULT TriggerEveii«( 
[in] LPSTR pEventName^ 
[in] IGXValLiA •plnVaUist, 
[in]BOOLayiicFlag 

yi 

HRESULT EnablcEveoK 
Pn] LPSm iiEveniNainB 

): 

HRESULT DisaUeEvcaK 
[in] LPSm pEveBMoBe 

yt 

HRESULT DdeteEveoK 
[in] LPSTR pEventflaine 

HRESULT Emin3Evenls( 

[out] IGXEnumCMgect **ppEventi 

yi 

} 

DesdiptioaK 



OjeateEvcfBt 

pEvenO^imie: naBK of llie evem to be resisteied. 
appeventOJg: poiiwer to leiniBed ^pevent olaeet 

CreatcEvcnt creates a empty appevcnl object. Attributes and Actions can be set on the returned appeveniOlg. and 
ihen registered with AppEvenlMgr using RegsterEvek. Note that changes to appevei^ do not take effect untfl it 
is registered with die ManagfEr. 



RegisterEvcnt 

appeventOtg: pointer to appevent object Hut is to be registered. 
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Registers a appevent object whose attributes and actions have been setup. AH changes to appEventObj aie 
conmiitted to the server, and the registry. If an appevent object already exists for the given name, then that object is 
deleted and this new object will lake iu place. 

5 GetEvent 

pEven^ame: name of die eveat. 

appeventObj: pointer to letmncd i^wvent object 

GetEvent retrieves a appevent object for a given event name. 

10 TriggerEvent 

pEventName: name of 4e event to be triggered. 
pVaUist: input ValList tbat is passed to Actioas. 

syncFlag: boolean flag to denote if event ii to be triggered syncbonansly. 
TCggex. a specified appevent A coiv of pInValList is passed as ii^ut to an actioiis 

15 

If the Action is an applogic, then plnVaHjst is passed as iiqmt to that applogic. 

If the action is a nail, dien idnVaOist is cuntendy simpfy ignored. 

If d« action is a Servlet, then the enliie. oTto iiTUt vdHst a« avaiTaWe as attn^ 

is passed to tbe Servkt. 

20 

If ^/ncnag is FAI^ flien die evert is triggered, and die can inanediately renmis ^ 
to complete execntiott If the nag is TllUE. then diis can blocks untU the evert is e 



Actions are triggered exacdy in the order dwy have been added to dM appevert olgeet 

25 



30 

DisableEvert 

pEveniName: name of the e\ 
Disables a appevent 



35 

pEventName: name of flie event 

Delete a appevent from the system and the registry. 
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ppEvents: pointer to retunied enum object 

Enumerates all appevents that are registered widi tbe server. Ezch element of the returned Enum bbfect contains 
qtpevent object (of type IGXApi^ventOlg). 



5 interface IGXAppEventOlg { 

. HRESUI.TGetNanie( 

[out, sizeJs(nName)l LPSTO pName, 
[in, defaidt_value(2S6)] ULONG nName 
10 ); ~ 

HRESULT SetAttriboiM( 
[in] IGXValLisr* attiUsl 

); 

IS HR£SULTGetAttra>nies( 

[out] IGXValList** atirfjst 

): 

HRESULT AddActionC 
20 [in] IGXValLisf aclioB 

); 

HRESULT I>eleteAetiaas( 

); 

25 

HRESULT EDumActiau( 

[out] IGXEnumOtgecl** actioiit 

)! 

30 ); 

GetName 

pName: pointer to a iiqnit buffer. 
nName: size (rf^ input buffiB. 
35 Gels the name of tbe appevent The nanK is set when the olgect is created >ridi C^ 




Sets the attribute ValList of the appevenL Note thai dumges to an ^ipevent bliiecl aie not Tommilt ed until it 
40 registered widi Oe AppEvenlMgr. - 

GetAttribuies 

attrList: pointer to returned attribute vallist 
Gels die attribute valUst of a ^ppevent 

45 

AddAetkm 

action: iiqnit action vallist 
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AddAction appends an action to a ordered list of actions. When an event is triggered, the actions are executed 
exactly in the order they have been added. ValLisi entries describe Ae action being added, and vary from one type 



DckteActidu 

Delete all actions added to tiiu appevcnt object. 



Enumerates actioiu added lo this appevcnt object. Each enny in the letuiaed enuna olqect it a actioii viUist of type 
IGXValList 

Sample portion of registry: 

6 EVENTS2 0 

7 tstEvl 0 
0 EnaUe 4 1 

0 ActionMode 4 1 

0 Time 1 •H),10,20,3O.40,5a-0 •/•/• 



JSISql ^3UIDGX-{754CE8F7-8B7A-153F.<38B^0800207B8777) 

2 0 

S^kiRcq 1 HeIloWorldSeivlet3Usl-valI&aigii2-vidii2 

3 0 
luenee 4 3 

1 /u^chinta/appevjonfl 



0 NewReq 1 GUIDGX-{754CE8F7-8B7A-153F-a8B-080Q207B8777) 
35 7 tstEv2 0 
0 
0 
0 

8 1 0 
40 0 Sequcaee 4 1 

0 NewReq 1 GUIDGX-{754CE8F7-8B7A-153F^8B-0800207B8777}?J»l-heIlo0 



Reouest Stew 

45 In various embodiments, an Bn>lication server may handle requests using a WMldlow model of defmhig a 

series of steps for each ^e of request As a single exai^le, consider die appKcatitai server architecture diown in 
Figure 3, in which a request of four steps is processed. The first step may be to determine the appropriate entity to 
handle the reque^ For example, the executive server 202 may broker a request to the Java server 204 if the request 
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refenmccs a Java^ component, or to ihe C/C++ server 206 if the request references a C++ component, etc. At 
another level, the Java server 204 may determine which Java'"* component should handle a request. Thus, request 
Steps may have different meanings in different contexts. 

Continuing the example, the second step may be to load the entity found in step 1 above. For exanqile, the 
5 }8va server 204 engine may instantiate the appropriate Java™ object Some siq>s may not apply in certain contexts. 
For example, step 2 may not ^ly lo an executive server-level request, since the appropriate server pr process to 
hand off a request to is probably already nmniag. 

The third step may be to "ran" the entity using the request context. e.g. request parameters. For exainpie, 
this run step for the executive server may mean to send the request data to the Java server and await the results. For 
10 Ihe Java server, this run step may mean to run the Java™ craiqiancnt on the Java™ virtual machine. 

The fourth step may be to stream back the results generated in the third step to the originating requestor. 

DifTerent step lists may be deflned for each type of request. For example, the step list for a request 
referencing an Enterprise JavaBeu™ may be difTcrent from the step list fm a request referencing a Java™ ServleL 

This method of rqnesenting requests as a series of steps provides advantages sudi as die flexibiliqr of 
15 weaving stqn in any way desiR^ for a given levd: Also, stqis may be easily added into the step lisL Forexanple, 
tidiik tiaditional programmhig models may require code to be recompiled or reloaded in order to aher veqaeat 
logic, the step model allows a new slqi to sinqply be added. 

Request OueueinB 

20 Each request received from clients sudi as web servers may be packaged in a dau packet havit^ a' 

particular format. According to this fonaa^ a field in the data packet may specify a sub-protocoL Tbis sub- 
protocol may specify whidi stq> list to use fiv die requoL 

A request mana^ service and queue and thread managers arc discussed abm widi refim 
If a request needs to be queued, for example if all the request-handling dneads are busy processing requests, then 

25 the request may be placed into diflerem queues based on die type of request A thread pool may be associated widi 
each request queue. Threads in different thread pools may have different characteristics. For example, requests 
requiring XA behavior, as defined by the XA standard protocd^ may be placed in a request queue that has a 
associated thread pool comprising XA-enabled threads. If at some point while a request is being p w cesa ed it is 
detemuned dnt flw request needs io be handled by a difTaent ducad, then the request nay be le^pwued in the 

30 appropriate queue. For example, if a nan-XA-enaUed thread is processing a request, and die appUcatian losie 
determines dixt die request now requires XA bdiavior. diea the request may be lequened inio • icquen 
SB associated thread pool comprising XA-enabled threads. Optimizations are preferably penfonned so dnt te 
. request does not have to repeat die endreoveriieaddfbemg taken fhmi die network stadc,nnmarduded, 

35 Loitging Factlity 

In various embodiments, the application server may provide a robust, flexible logging facility, as descrfted 
in dus section. 'When logging is enabled, messages generated by application-level and system-level servwes-niy 
be logged. These messages describe die events diat occur while a service or appUcation is running. Forexam|de. 
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each time the server coimnunicates with a database, the logging facflity may lecoid flw resuhmg messaga 
generated by a database access service. 

Deteiminmg Types of Mess ages to Log 

Various types of messages may be logged. In one embodiment, messages are categorized into the fblIowii>g type« 

. Infomiation message. Describes the processing of a ie«juest or normal service activity, such as a status update. 
• Warning message. Describes a non-critical problem that might be an indication to . toiger problem. For 
example, when a service is unable to connect to a process, a warning message may be logged. 



10 • ErxOT message. 



Describes a critical faihire of a service, fiom which recovery is not likely. For example. mhcD 



A user interface may be provided to manage message loggmg. e.g..enabling/disabling logging, specifying 
the type, of messages to log. etc. An ewle • «er interface to manage message logging « 
15 to Figure 20. the M«cimum Entries f«M specifies d«m»cim«m number of entries that c«,exi«befo.e^ 
written to the log. The Write Interval field specifies the amount of time (in seconds) that elapses befine dila is 
wrioentodielQg. n« Message Type field specifies which types of message. shouU be logged (inftanD«ia«l 
n«»»e.. warning.. uMl/or emn.) 



20 l-ftg Message Fonmt 



• meMage type, such a. information, warning, or ee 

• servfce or appBcatidn compMieBt E> generating n 



The logging service can preferably be configured 

30 



to record saver and applicatioa mesnge. io any or all of Ae 



Process con«,les. By default, the process con«,le. may dispUy log message, aalhqr are generated. If logging 
is enabled and the server is enabled for automatic starnip (UNDO or interaction 
console, open and display d« log messages. This feature can be disbaled by de«lec^ 



35 

. Application log. The default application log file. For Windows KT. this may l« 

Viewer. Ihis is the deftnh. Provide, a mote comprehensive record of the server 
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messages. Warning and infonnation messages are not logged to the application log. AD messages are soned b; 



• ASCn text file. An ASOl text file, which the user can create and specify. Used for a more peimaneM 
5 of the server and application messages. AU messages are soned by their timestamp. 

• Database table. A database table which can be created and specified. This may be the most versatile logging 
destination and can be used when it is desired to sort. ^np. «id create reports of the logged messages. 

10 In one nnbodiment, the server may use a log buffer to store messages before they are wiinai to diB 

application log. an ASCT file, and/or database logs. Tliis buffer optimizes the performance of the application servtr 
by liminng the use of resonrees to continually update a log. The buffer is written to the destination when either the 
buffer interval times out or thei number of entries in the buffer exceeds the m a x i m um number allowed. 

15 The following messages seat to an ASCD text fUe iUustrate exemplary foimals of text messages: 
[11/18/97 11:11:12:0] info(l):GMS«l7:s( 
OxcOaSOlae. port 10818. group "MIS') - <q 

(11/18«7 11:11:18:2] warning (1):GMM19: duplicate server (host 
20 0xe0a80l7f, poit 10818) recognized, please contact sales reptesentMive for additional Ucenaea 



If messages are to be logged to a database, an event log database table may be crealBd. -Ftgae 21 ataatntes aa 
exemplary type of database table for logging messages. On some systems, supplied scripia m^ be nsed for 
antomaricaDysettiitg up database tahhs. TTie appKcation server logging service may map the message elementt to 



FileR 

As shown in Figure 20, the an>Ucation server logging feciUty may be configined to ntaie ASCQ log 
30 atschedidedtimeiiitervala. When a log file is rotated, the exMng log file may be closed and movi 

location, and a new log file may be creaied for recording flitther log events. Since log files are stamped wiHl tbe 
time and date diey are created, log file rotation helps organize log files into manageable units. The times at which 
the log files should be rotated m^ be tpet^d using a regular time interval, as ilhistraicd in Figure 20, or using a 
string expression. e.g.. by typing a stting into the field shown. In one embodiment, a string expression should be of 
35 die fimnat: 

isW/DD/MM 



where the fallowing table e;qilains each element of the c 
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Possible Valna 



hour of the day 




0- 59 

0-59 

0- 6(0 for Sunday) 

1- 31 

1- 12 



10 Eacb of these fields may be either an asteridc or a list of elements separated by commas. An elenwat is 

eidier a nnmber or two numbers separated by a mimis sign, indicating an inclusive range. An asterisk qiecifies all 
Iqgal values for that field. Fore3unq>le,die«tpiessioa: 
2,5-7Hh05/»/* 

specifies that loggmg should be rotated at 2:00am, S:00am, 6:00am and 7:00am eveiy Friday. The spedficatian of 
IS days can be made by two fields: day ofthe month (DD) and day of the week (W). If boOi are specified, then bodi 
may take effect " Fwexample^flieeaqiressiaB; 
l:0K>inS/* 

qiecifies that logging to a new file stans at 1:00am every Monday, as well as on die fifteendi cf each mondi. To 
specify days by only one field, the other field may be set to 

20 

b one enibodiment, the ftiOowiiig environment entries, which may be implemented as registry entries, are provided 
to manage log file rotatioB. A user intei&ce sudi as shown in Figure 20 maiy be provided to set dwse entries. 

• EnableRotation: Log fUe rotation win be enrided when set ID ■'1", or dtoAled when sc^ Bydefiul^log 
file rotation is disabled. 

25 • RotateUme: An expression string denoting the time at -wlMh Out log file is to be rotated. 

• TextPadi: In one embodiment, when log fUe rotation is not enabled, die name of eacb log file is based on te 
■ valne of die TextPath entry, phu the process ID of die logging process. IVhen log fUe rotatioD is enabled, die 
name of each k>g file is based on the vahie of the TextPadi entiy, phis the process ID, phn dw tune at ^AaA 
die file is created. A file name may be of die format <'extFkflP>_'')iracess-id>_<liine-«ieated>. wliae 

30 <TaaiPaSlt^ is die vahie of die TeztPtrdi entiy, ^<¥roccss-ic> is ds id of die loggiqg process, and <iine> 
created> is the time at wlndi loggiiig to die file staffed. 



Logging Web Server Reqaesls 

Tbe application server may be configured to log web server requests. For exanqile. a web server ph«-in 
35 sudi as shown in Figure 4 may send requests to die application server where they are processed. By tagging web 
server requests, request patterns anl other iiiqpcfftant request iiifoiiiiatiasi nuy be tradnd. 

Wd> server requests may include HTTP requests. A web server HTTP request may be divided into 
standardized HTTP vatuUes used by the wdi server to manage requests. The ^licatioa server mqr include diese 
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or a subset of these HTTP variables to be logged. Variables may be added to the list if additional log iaforoiation is 
desired. In one embodiment, each HTTP variable is mapped to a fleld name in a database table. Figure 22 
illustrates an exemplary type of database table for logging web server requests. On some systems, supplied sciipis 
may be used for automatically setting up such a taUe. 

Note that Figine 22 illustrates a field name of "logtime*' in the database table. Tlie a|q;iIicatioD iserver 
logging service may recdid the time that the message is created in (he logiane dattbase field. Note ibat database 
field name may be renamed. The fields fiom the database uble may be automatically mapped to web tawt 



10 Out of Storage Space Condition 

One problem that is not handled well, or not handled at all, by many application server logging facilities is 
an out-of-stcrage-space conditian. sudi as an out-of-disk-space c o nditi o n. Since many odier logging facilities do 
not handle an oiit-of-storage-q;>aoe condition gracefully, this condition causes many other a^ilication savers to &£!, 



Thus, when lunning out of stnage spaae, the application server majr aut om a t i c all y suspend logging imtil 
more storage space becomes available. Logging may dien resume when storage space becomes available. In one 
dnbodiment, it is guaranteed that when the application server suspoids logging for lade of storage space, a message 
to that eifect will be wrinen to the log file. The application server logging facility may i e aei ¥e a cenaxa amoimt of 
disk space to write such a message if necessary. The logging facilitjf may eiuppad loggiag Sat iSxe d urat ion of tibe 
out^-storage space condition, and then autcmiatically resume logging when the conditiaB is coneded. Tbe 
^pBcatioD server logging fiudlity m^ inonitor die amoum of availdde ston^ 



FiguK 23 is a flowchart diagram iUustiating onie embodimeHt of a nwthod for handling 
^ce craiditions. As shown, in stqi 500, an amount of storage space may be reserved, e^., at Ifae 
25 the logging service. This storage q>ace may be disk space or another type of media storage space, 

where messages are logged. Tbe amount of storage space reserved may vary, but is preferably a relatively i 
amount suitabte for logging an out-4>f-«torage qMce condition message, as described below. The storage space 
be reserved m aiv of various ways, dqpenfing on die particular operating systeo, pngnnonins langga^ 
As shown in stq» 502 and 504. the amount of slonge space currendy avaiUdis nmy be 
30 - poiodically. For example, the logging service may create a thmd that wakes tip periodically and pofams dw 
chedc. 

if an out-of>storage-8pace Condition is detected, dien message logging may be suspended, as shown in step 
506. In one embodiment, the logging service may singly ignore requests by client processes to log messages wlule 
message logging is suspended. Tbe logging service may return an arm code to die client indicating diat die 
35 message was not logged. 

In step 508, a message indicating the out-of>storagc-space condition may be kigged, using die storage 
qace reserved in step 500. in various embo^ments, other actions may also be taken in re^onse to an ontof- 
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As shown in step 510, the logging s«vice may periodkany check for available storage space and may 
resume message logging If storage space becomes available. For example, a thread may periodically -wake vp to 
peifonn this check. Upon resuming message logging, the lagging service may of course r»erve storage space for 
logging an out-of-storage-space condition again if necessary. 

As noted above. Figure 23 represents one embodiment of a method for handling out-of-stoiage-space 
conditions, and various steps may be added, combined, altered, etc. For example, the logging service may be 
operable to check for declining storage space and may alert an administrator, e.g., via an email, before such a low 
level of storage space is reached that message logging suspension becomes necessary. As another exaniple, in cue 
embodiment, the logging service may queue logging requests received fiom cKent prooesses in memoiy ^»Mle 
message logging is suspended and may atteiBpt to log dw messages once storage space becomes available. 

Aldiougfa the embodiments above have been described in considerabk detail, nmneroua variatiaaa and 
modiflcations will become apparent to those skilkd in die art once die above disclosnre is faOy qqpieciated. It ia 
intended diat the following claims be interpreted to embrace aO sudi variations and aoodificatiant. 
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1. A method for enabling application server request failover, the method coi np ris in g: 

a requesting thread ninning in a client conqniter sending a request to an application server, wherein die 
application server is operable to receive the request, process the request, and retuni request results to the requesting 

the requesting thread sleeping afia said sending the request to die apfdicatiao servo; 

Ae requestiBg dsead waking iip and sending ■ poU message to the applicatioB server, viaxm the poll 
message convrises infomiation identifying the request, wherein the application server is qpenble to icceiyc die 
poD message aiid l e s po n d by retuming ■ status of the request to die requesting dncni 

2. The method of claim I, further conqsrising: 

the requesting thread determining whether a response to the poll message is received fiom the application 



3. Tbe method of claim 2, further comprising: 

the requesting thread receiving a response to the poll niessage 

die requestxDg thread analyzing die reqionae to detemune 



fiom die application sencxj 



dK requesting diread remnamg to sleqi if dw applicaiion server is cun 



e application server if die applicatian server is not 




the application server to : 



7. The method of claim 6, wherein (he applicaticm server is a first qiplicatian 
application server cluster conqirising the first applicatirai server and a 



the requesting thread sending the request to die second application server. 
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8. The method of claim 6, fiirtherconqirifflng: 
the client computei periodical^ polling the applicatiox 
if the application server responds to said polling, the 
the cuwent state of the application server to reflect that the 
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g the information regarding 



9. The method of claim ^ 

wherein said updating the infbnnation regarding the c 
the application server did not reqwnd to the poll message result 
to llw qiplicatian servo. 

10. The method of claim 6, 



state of die i^catioD server to reflect 
e client 



e to the poll message is not received from d 
g that a response to ibt poll message is a 



11. Ttemediodafciaiml. 

wliaem said sending a poll message to the qppHcaiian a 
(UD^ message to flw i#Iicatiao server. 

12. Tbemediadofdaiml. 
wherein said requesting thn 



13. Then 
«4ierein said i 

periodically at time imcmls specified ai 

14. The mediod of claim 1, 



a poD I 
rvianna 



14. 



16u The method of claim 1, 
wherein the client conqniter is a ii 
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a requesting thread stored in the memory of the client computer, whesein the requestmg thread is operable 
to send a request to an application server c ompute ; 

an application server computer including a CPU and memory, wherein the application server is f^ietable to 
receive the request, process the request, and return request results to the requesting thread; 
5 a network comecting the client conqniter to die appficatiaa server conqntlec; 

wherein die requesting diread is executable to sleep after said sendmg dw request to die appUndon serven 

wherem die requesting diread is executable to wake iqi and send a poll message to die aRilicatifiin server, 
wherein die poll message conqwises infonnation identiiyxng die request, wherein die appIi^atioD server is apeiaUe 
to receive the poll message and respond by retuming a status of die request to die requesting dncad. 

10 

18. The system of claim 17. 

wherein the requesting thread is fitrther executable to deteinine whether a respon s e to die poU message is 



Bis. 

wiiereiiai die requestixig dncad is findier executable to receive a response to. die poO x 



20. The system of daim 19, 

wboon the lequesdng diread is fiirdier executable to letmn to sleep if die applicatioii server is cmen^ * 



21. The system of claim 19, 

wherein die requesting thread is further executable to re-send die request to the applicatian si 
applica ti on server is not cuneiilly processsing Ae teqneat. 



'(therein the requesting diread is further executable to determine d»t a 
received from die application server; 
wherein the requestn 

35 regarding the currem state of the application server to reflet that the application server did not respnid to the poO 
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23. The system of claim 22, wherein the application server computer is a first application server 
con^uter in an application server cluster comprising the first application server con^uter and a second a|^licatioD 
server coinputer. 

requesting dircad is forther executable to send die request U> die second application server 



7 is operable to; 
wherein, in response to receiving a response to die 
the client computer is operable to update the information 
leflect diat die applicatira server responded to said pollinfi 



lessagc firoin die ^ipliCBtion 
the current state of die 



25. The system at claim 77, 



mrent state of die apidicatioD scrar to reflect dnt 
■ in die clieiit tiiinnmlrr not sf iMiiiig future requests 



26. The system of claim 22, 
wherein said requesting thread determining 
ftx is acf p On i | > hslie d by 



diat a response to the poll message 



is not received from d 
D die pon message is n 




{sponi 

Kviaaus 



30. The system of claim 17, 
an application coflopanent nmniiq 
wherein the request references dn 
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31. The system of chim 30^ 

whetein ^e coinpoiient is 3 coiupouCDt from tlie group coiisistiiijg of* 

a JavaServer Page conqKment, a Java Servlet conqxneiit, an E 

32. The system of claim 30, 
wherein the cliem conoputer is a web server computer. 



33. A memoiy medium con^msmg program mstnictiaDs cperabh: to ii 
■ icqoestiiig thread ruimmg in a client conqntter sending ■ request to an application server, wherein die 
10 application server is opc i 4 b lc to receive the request^ pr ocess the re<|tte^ and return r e qu e st results to die re(|uesling 

die requesting thread sleeping after said sending the request to die application serva; 
die requesting thread waking vp and sending a poll message to the application server, wherein the poll 
message comprises informadon identifying the request, wherein the application server is openUe to receive die 
IS poUinessageaiid respond by retutmng a sums ofdw request to die xequestiitgdiread. 



34. Tbe I 



I -of 33, find 

^ whfftfifT a response to Ihe poD 



35. Tlie incittoty medhim of dann 34, fixrdier < 
iho jcqncstiQg; ftr^**^ xcccsving a i espouse to fhe pc^ message fion tiw appUcatmi sewcXf 




' mednm of "^I'lnnB 35^ fiirthcr isdMkyi niH|^ ] 



' TncdiufD <tf clam 3St Aaither conipnsing ptognm instnictKXis i 
re^scnding ^e request to fhc applicatioii aewcr if tfie applicalioii scfvcf la fiot 



38. Tlie memoxy 



mrdhim of claim 34, wlioein die client conqniter is <^>erable to maintain 
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e requesting diread detennining that a response to the poll message is not 



die reqnestiiig Onad causias die elient conqputer to update the inf«iiiati(m legndiag 1 
die applicatioa server to zeflect that die applicatian server did not lespond to die poll message. 



e cuncut state of 



39. Tlie memoiy medimn of claim 38. wherein the application server is a first 
application server chister conqnising die first application server and a sect 



afiplicatioa server in aa 



toiin 



thf r- T-i^g flmsad sendmg the request te die second applin 
40. The memory medium of claim 38, findier con 



die client conqiuter periodically polling die applicatian server; 
if die application server responds to said polling, the client coxnputer u 
15 die current state of the application server to reflect diat die application server responded to said poIIia8> 




die cunent stile cd- die afpUeatian eerrcr to tcfleetdi 



wlierexn said requesting diread detennining diat a response to die poll n 
Bpplicatitm server is accomplished hy die requesting doead detomining diat a res 
25 received fitan die 



B is not received from Oe 



apolln 



(UDP) 



44. nien 

wherein said requesting dvead waking vp and sending a poU x 



peifoimed petiodteaOy at time intervals specified by aa ai 
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46. The memoiy medium of claim 33, 

wherein the request references a component nmning on die ^licatiai » 



47. The memoiy medium of claun4<^ 
Khc co mpijucn t is & 'ctinxpoiuBt from 

a JavaSoyer Page canpanent. a lava Servlet conqponent, an Eat 



iMdwRin the client conipuiei is a web sener GompntCT. 



S3 
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Web Server CGent 240 



Web Server Plug-lr) 242 
(NSAPI, ISAPI. CGI) 




Load 
Balar)oer 





Client Computer 250 
(Java, C/C++) 




DCOM 


llOP 






oa 

Service 


RMI 









ApiJicatiori Server .230 







Protocol Manager Service ^ 






NSAPI 
Listener 




ISAPI 
Listener 




CG! ^ 
Listena* 




Application 
Server 




DCOM II llOP 1 














Communication 
Protocol 








HTTP/HTTPS 





















Load Balandng Service 222 



Monitor Distritnilor 



Request Manage Service 2 



Reque^ 




Thread 




Queue 


Manager 




Manager 




Manager 



Fig. 4 
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Web Sen/er Client 300 



Web Server Plug-In 302 
(NSAPI. ISAPI, CGI) 



Load Balancer Component 304 




table of server and/ 
or component 
response times 

3gs 






Application Server 
308A 



Applicattion Server 



Application Sen«r 
308C 



Fig. 5 
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Server Load Criteria 



Description 



CPU Load 



Disk Input/Output 



Memory Thrash 



The average percentage of time all prooessore in 
the server are in use 

The rate at which the system is issuing read and 
write operations to the iiard disic 

The number of pages read from or written to the 
hard disic to resolve memory references to pages 
that were not in memory at the time of the reference 



Number of Requests Queued The number of user and application requests a 
server is currently processing 



Server Response Time 



Average response time from the server for ail 
application components 

Fig. B 



Application Component 
Performance Criteria 



Description 



Cached Results Available 
Lowest Average Execution Time 
Most Recently Executed 
Fewest Executions 



Application Component 
Response Time 



Signals whether the execution results of the 
application component aie cached 

The time the application con^ionent takes to 
run on each appfication senw. 

The application server that most recently ran 
the application component 

The numtier of ti'mes tiie application 
component has run on each application 
server 

Average response time from a specific 
application server for the application 
component 



Fig. 9 
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Fig. 11 
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LoadBalandhg | User Defined oaeria (MAS Driven) 



SMverLoMlOitariB | AppBcatiaii CDmponnM CrMeriB | 
Aitalicaliwi ConvmwnfcllesDeineTme: 



Lowest Aeeraoe Execution Time: 



Fig. 12 
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- Load Batomino Method: , , , ____ 

I Load Balancing: juaer Defined Cr ierio (MAS Di-iver) y\ 

Server Loedailate | AopBcatian Coirponert Oteria | . Adranccd SetUnn* | 
Base BRMKicasMJ^Bitelnter\at seconds 



Server LoaA 

Application Componert OieriK jgp 



Update intervala - 



Dis»UO: 

Mbimt/ ThrcstK 
rimbe' oi Reqiests Ci 

MsMimunHopc: 




Fig. 13 
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Set AppiBillan Orai^p Access GonM^ 



ApplicsUsn Croup Cw 





Type 


=nabinl| Mods 


StfckyLB 


Bean GXAppitsOnftieBoaialorejBCOuntJBoakA... 
Bean OXAppxtsOnlneBankjuser JUserOetals 


Java 
Java 


ki iLocal 
^ Local 




Bean GXAppjnsOnlineBanfcxiataaccessJDalaAc... 


Java 


^ Local 






Java 


0 ILocai 




ServietnsOnheBootcstore_BooKstore 


Java 


a, Local 




Bean OXApp jnOnkteBaaksiarejcasNerXashier 


Java 


^ Local 




Bean OXAppJta^MneBankjcwstomer JBankCu^... 


Java 


a lu*- 
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client computer sends a request to an 
application server using a custom wire- 
level communication protocol 

4za 



I 



requesting thread sleeps 




m 




I 


requesting thread periodically wa 


kes up 


and polls application sen/ei 




474 






client computer updates infbnnation 
regarding application sender status 
486 



client computer periodically polls 
application server to detemnine whether 
it is online again 





requesting thread le-sends request 



requesting tli 


read returns to sleep 
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administrator specifies a set of class files to 
be treated as a bundle 
44& 



administrator requeste class bundle 
to be deployed 
4^ 



deployer manager obtains lock to 
dirtyClassListLock 
4M. 



deployer manager copies all class files in the 
bundle to their appropriate runtime locations bi 
the file system 



deployer manager releases dirtyClassLlstLodc 
448 



timed thread ot>tains dirtyClassListLock and 
dynamically reloads modified classes 
in bundle 
450 



Fig. 18 
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return JSP response 
616 



Fig. 19 
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Database field name. 



Description 



Data type 



evttype 

evtcategory 
evtstring 



Date and time the 
message was created 



Message type, such as 
information, warning, or 



Service or application 
component ID 



Date/Time 
Numt)er 

Number 
Text 



Fig. 2i 



Default HTTP variables 


Default database field nan 


le Datatype 


WA 


logtime 


Date/Time 


CONTENT_LENGTH 


contentjength 


Numter 


CONTENTJTYPE 


contentjtype 


Text 


HTTP_ACCEPT 


accept 


Text 


HrrP_CONNECTION 


connection 


Text 


HTTP^HOST 


host 


Text 


HTTP^REFERER 


referer 


Text 


KnP_USER_AGENT 


user_agent 


Text 


PATHJNFO 


uri 


Text 


REMOTE_ADDR 


iP 


Text 


REQUEST.METHOD 




Text 


SERVER_PROT0COL 


protocol 


Text 



Fig. 22 
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reserve storage space at startup of 
logging service 
500 



periodically check for out-of-storage 
space condition 




suspend message logging 
^ 



use reserved storage space to log a 
message indicating the out-of-storage 
space condition 

SSS. 

i 

periodically check for available storage 
space and resume message togging if 
space is available 



Fig. 23 
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